Contact email@example.com or (415) 570-8502 to start your trial.
Terms and Definitions
When you design a flow, the individual steps are called “activities”. Activities perform tasks like call an API, send a text message, or insert a record into a database. In general we find that it is easier to maintain flows over time if they are limited to a few dozen activities. Flows are composable and can be designed to call other flows, so, it’s good design practice to break things up into manageable pieces.
The number of activities allocated to your app is driven by the number of flows. If, for example, you are using the Trial tier (which grants 5 flows), then you will be allowed a maximum of 100 activities spread across these 5 flows (an average of 20 activities per flow). If you need more activities than your plan allows, consider moving to another plan or purchasing additional flows, each of which will allow you to add an additional 20 activities.
Global Data Models
Intwixt uses models to define the structure of the data as it flows from activity to activity. It doesn’t matter if the activity is sending an SMS, reading from a database, or calling a RESTful API. In every case, data is being exchanged, and that exchange must be clearly documented using a data model. Defining a global data model saves time and ensures consistency, allowing you to re-use the same definitions across all of your flows.
Every flow begins with a Trigger activity that is “triggered” by an outside event. For example, there are triggers for Slack events, triggers for Messenger events, and triggers for HTTP events. The trigger type that receives HTTP events is called an HTTP Receiver Trigger. If you include a trigger of this type in a flow, there will be a corresponding HTTP API when the flow is activated (its “endpoint”).
HTTP endpoints are documented using the Open API 2.0 specification format and are fully managed by Intwixt. All aspects of the HTTP endpoint can be configured including method, path, signature, response headers and more by configuring the Receiver Trigger within the flow designer.
Users of paid applications are allowed to invite other Intwixt developers to become members of their app at the rate specified. For example, an application owner using the Plus tier would pay $117 per month if they were to invite two additional developers (99 + 9 + 9).
Real-Time Event Stream
We publish a detailed set of life-cycle events to CloudWatch when your application is run, allowing you to set custom triggers or forward the events to an analytics engine of your choosing. These include:
App Life-cycle Events
App Start | Credential in Use | App Stop
Flow Life-cycle Events
Flow Activate | Activity Initialize | Trigger Initialize | Trigger Destroy | Flow Deactivate
Job Life-cycle Events
Job Start | Job Stop | Job Stop With Error
Activity Life-cycle Events
Activity Start | Activity in Waiting | Activity Retry | Activity Stop | Activity Stop With Error
Flows represent the logic for your application. They are authored using Intwixt’s Web-based designer or using the REST APIs. When flows are activated and run on the Intwixt backend, the engine executes the activities defined in the flow one-by-one.
As your application grows over time, you you may need more flows than your chosen plan allows. You can upgrade your plan or choose to purchase additional flows at the rate offered by your plan.
Each app is allocated a fixed number of activity calls at the beginning of each monthly billing cycle. For example, Trial tier members are granted 1,000 activity calls each month. A single call is then decremented from this allotment each time an activity in a flow is run.
If an app consumes more activity calls than allocated for the billing cycle, additional calls can be purchased at the rate established by the tier. For example, Plus tier members are charged .001USD/activity once they use up the 10,000 credits granted by the plan each month.
Note that there are situations where additional calls are deducted when a single activity completes, including:
long-running activity calls lasting longer than 1 hour
activity calls with payloads larger than 10KB
activity calls using premium features like sending SMS messages, using Intwixt’s Twilio account
Interfaces are used for dynamic call routing. At runtime, the engine can direct a call to a specific interface instance (another flow) which handles the call. The contract for this flow must adhere to the contract for the interface (its inputs, outputs and errors must align), but beyond this limitation the instance can add additional properties to its models. When used in conjunction with conditional routing, interface routing can capably handle complex routing semantics, even when the full set of message properties are unknown at design time. Interfaces allow you to grow your application over time without service interruption.
We provide managed connectors to simplify connecting to popular external services out of the box. However, there are times when you will need to call a service not managed by Intwixt. To facilitate this, Intwixt provides several import utilities for creating your own private connectors. We support the Open API format and can also connect using sample JSON when no spec is available.
Private connectors behave like first-class citizens, allowing you to orchestrate them in your flows alongside the activities that Intwixt provides.
Setting alarms on critical events is a necessary component of a properly functioning ops center. You have to know when things go wrong. Intwixt does this one better by integrating AI into Pro and Enterprise tiers. When you activate your app, we generate a custom ML profile specific to the flows and activities you define.
Each time a fault occurs or a goal is reached, the details are passed to the AI system. Over time, the alerts become increasingly predictive, changing from “a fault just happened” to “a fault is about to happen” or alerting when there is opportunity to improve the process.
As flows are run and complete successfully, their profile and activity relationships are saved to a ML Data Store. Over time, Intwixt learns which activities comprise a “good” flow (basically those that complete successfully). These are then fed to the design system, which recommends things like which errors to catch in a particular scenario.
Users of the Pro tier can register a CloudWatch instance for their app. Intwixt will then generate a dashboard representing a rollup of the running application, including a real-time analysis of job faults and performance.
The dashboard further isolates activities involving people from activity calls involving systems to provide an accurate understanding of how the system is performing under load.