This document provides an overview of the Intwixt platform, including how it compares to other frameworks and approaches. It details both the tools used for development as well as key concepts and principles for developing robust solutions.

What is Intwixt 4

Integration Platform Comparisons 5

Stateful Process Engine 5

Integrated Data Services 6

RESTful by Design 6

Traditional Platform Comparisons 7

Comparison 1 of 4 7

Code 7

Intwixt 8

Comparison 2 of 4 8

Code 8

Intwixt 9

Comparison 3 of 4 11

Code 11

Intwixt 12

Comparison 4 of 4 12

Intwixt 12

Code 13

HTML5-Based Web App 13

Components 13

Site Index 13

Page | Dashboard 14

Page | Flows 15

View Mode | By Tag 15

View Mode | By Title 15

View Mode | By Search Term 16

Menu | Create Generic Flow 17

Menu | Create Chatbot Flow 18

Menu | Create Data Access Flow 19

Menu | Create Alexa Dialog Flow 20

Menu | Import Flow 22

Menu | Environment Variables 23

Page | Flow Designer 24

Designer Canvas 25

Augmentation mode 25

Modification mode 25

Canvas Menu 26

Palette | Settings 27

Tab | Overview 27

Tab | Settings 28

Tab | Models 30

Tab | Credentials 33

Tab | Preferences 34

Palette | Trigger 35

Tab | Overview 36

Tab | Settings 36

Tab | Output 36

Tab | Advanced 37

Palette | Activity 38

Tab | Overview 38

Conditions 39

Tab | Settings 43

Tab | Inputs 44

Tab | Outputs 45

Tab | Milestones 46

Tab | Advanced 46

Palette | Activity Type Selector 46

Option 1 | Chose a system activity/trigger 46

Option 2 | Search for an activity or trigger 48

Option 3 | Select a flow to invoke 49

Page | APIs 49

Page | Data / Models 49

Menu | Create Model 50

Menu | Environment Variables 50

Page | Credentials 51

Page | Connectors 51

Native Connectors 51

API Connectors 52

Page | Account Settings 52

Tab | Profile 53

Tab | Plan 54

Tab | Usage 55

Tab | Usage History 56

Tab | Billing 57

Tab | Billing History 58

Tab | Notifications 59

Tab | Advanced 60

Concepts 60

Intwixt Schema Format 60

Schema Principles 60

Schema Tooling 61

Schema Structures 61

Schema Symbols 64

Schema Tables 68

Schema Data 69

Data Mapping 70

Data Mapping Scope 70

Data Mapping Principles 73

Data Mapping Types 75

Type | Static mapping 75

Type | Variable mapping 75

Type | Field mapping 75

Type | Activity mapping 76

Type | Transformer mapping 76

Transformer | String 76

Transformer | Math 79

Transformer | Entity 81

Transformer | Date 83

Transformer | Collection 91

Transformer | JSON 96

Conditional Processing 97

Conditional Processing Tools 97

Condition | If All Are True 98

Condition | If Any Are True 99

Condition | Otherwise 99

Condition | Otherwise Error 100

Activity Modeling 102

Modeling Principles 102

System Activity Types 102

Type | Receiver 103

Type | Return 114

Type | Map and Iterate 116

Type | Collect 123

Type | Invoke 127

Type | Error 132

Complex JSON Modeling 139

What is Intwixt

Intwixt is an Integration Platform with a focus on building bots and instant apps. Our cloud-hosted solution provides both design and runtime services. Using our visual tools, developers design process flows that orchestrate people and APIs. Flows can be arbitrarily complex and can even invoke other flows. This compositional approach allows the system to model complexity using reusable, modular components.

Once a flow is complete, users activate and run them atop the Intwixt engine. We refer to actively running flows as apps, bots, or chatbots. We leave it up to our users to choose the name that best describes the solution they’re building.

It can be difficult for developers unaccustomed to integration architectures to understand what a “solution” looks like or how to even approach them. For those accustomed to writing procedural or object-oriented code, it can almost feel like magic once you discover model-driven approaches.

Consider the following Intwixt flow that was authored to handle a standard user registration use case. It includes all of the common features such as sign-in, sign-out, get profile, and register. It also supports password reset and email confirmation.

Designing a solution like this takes about a day to complete in Intwixt. It’s a logical task for sure, but it involves modeling flows and configuration, not writing code. For the developer, all responsibility is shifted to defining models. Everything else is just connecting the dots.

Integration Platform Comparisons

Integration architectures shine when orchestrating heterogenous APIs and services. By definition they connect most anything quite well. But people are inherently unpredictable, necessitating additional logic to model their delays and unexpected responses.

As we set about creating Intwixt, we wanted to extend the power of integration architectures with a modern twist that’s more targeted at conversational and front-office use cases. By combining a stateful process engine with integrated data and RESTful services, we see an opportunity to apply the power and discipline of integration to the convoluted task of organizing people and building end-user apps and bots.

Stateful Process Engine

We discovered early on that adding state management to the Intwixt platform simplifies conversational use cases substantially for developers. People are inherently difficult to model using standard process engines. They respond with unpredictable phrases on their own timeline. By adding state, we replaced unpredictability with configuration, freeing developers to simply storyboard at the level of business.

Integrated Data Services

It’s rare to build a solution that doesn’t read and write data. The need is so pervasive that we include a NoSQL Data Service Connector. Creating a table is as easy as specifying the field names. All records are indexed and searchable and can be accessed and updated via RESTful API calls. Data can even be exposed as a real-time data feed to any HTTP client that supports the HTML5 WebSocket standard.


RESTful by Design

Intwixt generates all API documentation when a flow is activated, documenting every HTTP endpoint, including examples. Here is the Open API (Swagger) specification that was generated by Intwixt when the user registration flow (shown above) was activated. All RESTful endpoints are deployed and managed by Intwixt, providing a truly serverless development experience.

These are just a few of the features of Intwixt, but we hope it gives a sense of just how powerful integration principles can be, especially when enhanced with State, Data, and REST. And in a world where more APIs come online each day, there’s no better way to embrace change than by choosing a platform that expects it.

Traditional Platform Comparisons

While traditional platforms use code to author solutions, Intwixt uses schemas and process models. To illustrate what’s different and what’s the same, the following series of examples will present the same use case using a code-based approach and a model-based approach like Intwixt. For a given ID, the solution will return a Person (a simple object with first and last names).

Comparison 1 of 4


With code-based approaches, you author the function and provide a description.

NOTE: This example uses a signature common to Node.js functions where a callback function is passed to handle the output (common to asynchronous, event-driven systems).


* Gets a person for a given ID


function get_person(id, callback) {



Intwixt models top-level functions using a Receiver Trigger. Open the Flow Designer and click the ‘+’ icon to add one. Add a title and description.

Comparison 2 of 4


With the code-based approach, one would next document the function’s signature, including the inputs, outputs, and errors.

NOTE: These examples use the standard JSDoc format to help illustrate as clearly as possible the overlap between code- and model-driven approaches. If you’re the type of developer who documents liberally, you’ll quickly see that model-driven development shares a lot in common with well-documented code.


* Person object definition


* @typedef Person {Object}

* @property id {string} Person ID

* @property first {string} First name

* @property last {string} Last name



* Callback signature for a Person. Returns one of err|Person


* @callback PersonCallback

* @param err {string|null}

* @param person {Person|null}



* Gets a person for a given ID


* @param id {string} Person ID

* @param callback {PersonCallback} Returns the person (or err)


function get_person(id, callback) {



Intwixt has the same documentary requirements as well-commented code. Users begin by providing a sample JSON document. Intwixt then generates the model/schema.

Once defined, the model is referenced by the trigger to define its signature. Notice how the Person model defined above is now being referenced to define the Response model field.

Comparison 3 of 4


The last step is to actually do the work (what happens inside the function). Since this is just an example, it’s configured to return static values and echo the id. In a real scenario there would be a database or service call to resolve the person.

function get_person(id, callback) {

var person = {

"id": id,

"first": "Markus",

"last": "Schmidt"


callback(null, person);



Intwixt provides a Return activity for generating function output. As with the code-based example, the Id will be echoed, while the First and Last fields will use static strings: Markus and Schmidt.

NOTE: The Return activity is the Intwixt equivalent of a callback function and is used to package and return the final response message from a flow.

Comparison 4 of 4


An application is never truly complete. It either evolves or stagnates as it interacts with an ever-changing environment. A key quality of Intwixt (and integration platforms in general) is that their tooling is built to handle change. They’re meant to connect anything, even moving targets.

Given our example use case (to get a person by their ID), it’s not too much more effort to just add an activity with data searching ability (Get Record by KEY). Because the models have already been defined for the flow, this is just a configuration exercise. With model-driven development, the hard work is always up front when you define your models. The remaining work is reduced to wiring and configuration as shown here.



If it were possible to show the code-based equivalent, we would show it. But in fact, Intwixt is a platform, making it difficult to compare with a code-centric approach. Intwixt is more than just a process modeling tool, it’s a stateful platform with integrated REST and data services.

HTML5-Based Web App

Every feature of the Intwixt platform (including the Flow Designer) can be accessed using the HTML5 Web app Register for an account at or send a text to the Intwixt registration bot at 415-993-5470. Once you have an account, you can access the Web app from any device and can even save the app to your home screen on your phone or tablet for easy access.


This section details the components that comprise the Intwixt HTML5 Web app.

Site Index

The Site Index contains a list of all top-level pages in the HTML5 Web app. Most require the user to sign in, but the Connectors and Docs are available to the curious.

Page | Dashboard

The dashboard ( gives a full view of a user’s development and runtime environment, including their data models, credentials, published APIs and flows. It’s a useful starting point when monitoring running bots and apps.

Page | Flows

View Mode | By Tag

By default, the Flows Page is categorized according to a dynamic set of tag(s) assigned by the developer when they create each flow. Every flow may define up to three tags (and therefore may appear multiple times on the flows page when viewing flows by tag name). Here, for example, are the flows that comprise the Intwixt Messenger Bot that helps register new users. The ‘TOBI MODULE’ tag has been expanded to reveal those flows that declare it. (Tobi is the name of our Messenger Bot and these are the reusable modules we’ve defined for handling common requests.)

Interested in reading the rest?

Text Free to 415-993-5470 to register for an Intwixt account.