The icon representing the component in the UI. It must be in the Data URI image format as described here: https://en.wikipedia.org/wiki/Data_URI_scheme. image/png or image/svg+xml image types are recommended. Example:

{
    "icon": "data:image/svg+xml;base64,PD94bWwgdmV..."
}

Appmixer is a white-label AI workflow automation platform built for SaaS vendors. It lets you embed a fully native AI workflow automation hub directly into your product — so your users can automate workflows, connect third-party apps, and run AI agents, all without leaving your platform.

Appmixer is available as a cloud solution or as a self-hosted deployment, giving you full control over your data and infrastructure.

Start by building some automation templates for your Automation Hub.

The Automation Hub is a one-stop shop for automations and AI agents for your end users.

Get started with the Automation Hub:

1. Build and Publish a Template

2. Customize and Share Your Hub

3. Embed Your Automation Hub

Embed your own Hub to allow users to:

• Browse and start Automations pre-built by your team

• Customize pre-built Automations

• Manage Logs and Accounts for their Automations

Your team can easily manage the Hub:

• Organize automations into categories (shown as tabs in the Hub)

• Adjust the look and feel of the Hub

• Monitor health and statistics of Hub Automations

• Define who can access specific automations

Please visit the for end-user tutorials.

(optional)

The label of your component. If not label is specified, then last part of name will be used when component is dropped into Designer. If your component name is appmixer.twitter.statuses.CreateTweet then CreateTweet will be name of the component unless you specify label property. This allows you to use spaces as opposed to the name property.

All published templates are available in the Automation Hub - an all-in-one embeddable widget that you can use to present automations to your end users.

The Automation Hub provides these features to your users out of the box:

• Starting and managing automations including logs and accounts

• Searching and filtering

• Customization of pre-built automations (you can choose to enable or disable this option)

Optional. A description of your component written for the AI Copilot rather than for the Designer UI. Copilot's component discovery prefers aiDescription and falls back to , so a connector that does not define it behaves exactly as before.

Use it where the UI description is too short to steer the model — say what the component is for, and the nearest thing it is not for:

aiDescription may be at most 1000 characters. It is read on every component-discovery call, which lists every component of an app at once, so keep it to a few sentences.

The field is also accepted in module and service manifests.

When set to true, the component will receive signals in regular intervals from the engine. The tick() Component Virtual method will be called in those intervals (see ). This is especially useful for trigger-type of components that need to poll a certain API for changes. The polling interval can be set by the COMPONENT_POLLING_INTERVAL environment variable (for custom on-prem installations only). The default is 60000 (ms), i.e. 1 minute.

(required)

The name of your component. The name must have the following format: [vendor].[service].[module].[component]. Note that all the parts of the name must contain alphanumeric characters only. For example:

The vendor part of the component name is the ID of the author of the component set. service and module allows you to organize your components into categories. These categories not only help you keep your components in a tidy hierarchical structure but it also has a meaning in that you can share your authentication and quota definitions between modules and components (more on that later). component describes the actual component activity.

Description of your component. The description is displayed in the Designer UI inspector panel like this:

The description should not be longer than a sentence or two. Example:

The component manifest provides information about a component (such as name, icon, author, description and input/outputs definition) in a JSON text file. The manifest file must be named component.json.

Example manifest file:

{
    "name": "appmixer.utils.controls.OnStart",
    "author": "Martin Krčmář <martin@client.io>",
    "label": "On Flow Start",
    "description": "This trigger fires once and only once the flow starts.",
    "icon": "data:image/svg+xml;base64,PD94bWwgdmV...",
    "outPorts": [
        {
            "name": "out",
            "schema": {
                "properties": {
                    "started": {
                        "type": "string",
                        "format": "date-time"
                    }
                },
                "required": [ "started" ]
            },
            "options": [
                { "label": "Start time", "value": "started" }
            ]
        }
    ]
}

Being equipped to troubleshoot your customers' integrations is crucial, as there are myriad reasons why integrations might encounter issues. The most frequent problems stem from integration misconfigurations, your end-users revoking previously granted permissions, alterations in third-party apps leading to the use of outdated data, service outages, and various other factors. When your customers encounter difficulties, it's essential to have the necessary tools to investigate and understand the causes of these issues. This tutorial is designed to provide you with the knowledge and resources needed for effective troubleshooting.

Look up your users

To access information on your end-users, navigate to the "Admin" interface within the Appmixer Studio and proceed to the "Users" page. Please note, you must possess admin user privileges to access the "Admin" interface:

In the "Users" section, you'll find a comprehensive list of all users within the system. The interface allows you to search for users based on multiple criteria, with email being the most common search parameter. Upon locating a user, you can click on the Flows icon () to view all the flows associated with that user, including integration instances and automations.

Inspect Flows (integrations or automations)

After locating the flow you intend to troubleshoot, proceed to examine the flow's logs and configuration. Click on the "Logs" link to view the flow's logs, and utilize the "Flow" link to inspect the flow's configuration in the Appmixer Designer.

As an Appmixer admin user, you have the capability to directly make minor adjustments to a flow from within the designer. However, it's important to recognize the boundaries of such modifications. For instance, re-authenticating to the applications within the flow is not possible, as authentication was initially performed by the end-user. Additionally, altering the flow's structure is discouraged, as it may necessitate new inputs from the end-user. Focus on implementing small, necessary corrections, and guide the end-user to undertake more significant changes by re-configuring their integrations according to your instructions.

Returns a list of the public files

GET [TENANT_API_URL]/public-files

The list returned does not contain the contents of the files.

[
  {
    "filename"

Upload a public file

POST [TENANT_API_URL]/public-files

curl --location 'https://acme.com/public-files' --header 'Authorization: bearer [the-admin-token]' --form 'file=@"/tmp/icon.png"' --form 'filename="icon.png"'

Request Body

DELETE [TENANT_API_URL]/public-files/:filename

The authentication service and parameters. For example:

{
    "auth": {
        "service": "appmixer:google",
        "scope": [
            "https://mail.google.com/",
            "https://www.googleapis.com/auth/gmail.compose",
            "https://www.googleapis.com/auth/gmail.send"
        ]
    }
}

The auth.service identifies the authentication module that will be used to authenticate the user to the service that the component uses. It must have the following format: [vendor]:[service]. The Appmixer engine looks up the auth.js file under that vendor and service category. auth.scope provides additional parameters to the authentication module. See the Authentication section for more details.

When auth is defined, the component will have a section in the Designer UI inspector requiring the user to select from existing accounts or connect a new account. Only after an account is selected the user can continue configuring other properties of the component.

Components are the building blocks of integrations and automations in Appmixer. Each component in a flow reacts on incoming messages, processes them and produces outgoing messages. User can wire components together to define complex workflows and integrations. Usually, components call external APIs but they can also do some internal processing, logic or scheduling.

Take the example above. There are three components in the flow. The first one (Timer) we call a trigger because it does not have any input ports and so the component generates outgoing messages based on its internal logic. In our case, the Timer component sends messages to its output port out in regular intervals that the user can specify in the UI. As soon as a message leaves an output port, it travels through all the connected links to input ports of other connected components. In our scenario, when a message leaves the out port of our Timer, it goes to the location input port of the GetCurrentWeather component. As soon as the GetCurrentWeather component receives a message on its input port, it starts processing it. In this case, it requests current weather information from the https://openweathermap.org API. Once a response is received from the API, the component continues to send the result to its output port weather. Note that the location for which we're requesting the current weather can be specified by the user in the UI. The process then repeats for all the other connected components until no message is generated on an output port or there is no other component connected.

To make our example flow complete, it is important to note that any component can be configured using data generated on output ports of any component back in the chain of connected components. In our example, our SendChannelMessage component sends a message on Slack channel #qa-messages with text containing the city, humidity, pressure and temperature as it was received from the weather API. The user configures the flow in the designer UI simply by selecting placeholders (variables in the Appmixer jargon) that will eventually be replaced when the flow goes to the running state and the actual data is available.

Components have some important properties that we should mention before diving into the details:

• Components don't know about each other. All components are totally independent and loosely coupled. They only react on incoming messages and produce outgoing messages. The linkage between components is not internal to the components themselves but rather a mechanism of the Appmixer internal engine and its protocol.

• Components are black-boxes to the Appmixer engine. The engine does not know and also does not need to know what components internally do and how they are implemented. It only wires them together through ports and makes sure messages are always delivered and in the right order.

Introduction

By default the Each component sends all the items of a list at once. The steps in the loop body then call the target API for all the items at the same time, which can hit its rate limit.

Set Delay on Each to space the items out. Each then sends one item, waits the given number of milliseconds, sends the next one, and so on.

Settings

• Delay: the pause between two items in milliseconds, from 0 to 60000 (one minute). 0 or empty means no delay.

For example, an API that allows 10 requests per second needs a delay of at least 100 ms.

How it works

• Each sends the items in their list order, with the pause between them. The item messages look the same as in the default mode: Index, Value, Items Count and Correlation ID.

• done is sent once the last item has been sent.

• A long list is processed in batches of up to three minutes in the background, so a delayed loop can run for a long time without blocking the flow. If the engine delivers the input message again after an error, the loop continues from the last sent item instead of starting over.

• Join Each works the same as in a parallel loop, see .

The Analytics dashboard gives you a real-time view of how your end users are engaging with your Automation Hub - what's running, what's being adopted, and where issues are occurring.

Access Analytics from the Automation Hub section in the main navigation menu.

What you'll find

Summary metrics

Four tiles at the top of the page give you an at-a-glance health check of your Hub:

• Total Running Instances — the number of active integration instances currently running across all your end users

• Active Users (Last 30d) — how many users have been active in the past 30 days, with a percentage change compared to the previous period

• Data Messages (Last 30d) — total data messages processed, with a percentage change compared to the previous period

• Success Rate (Last 30d) — the share of flow runs that completed without errors

Template lists

Below the summary tiles, four lists give you a deeper breakdown by template:

• Most Popular Templates — ranked by number of active instances

• Most Active Templates — ranked by volume of data messages processed

• Template Adoption — ranked by new activations in the last 30 days

• Success Rate — ranked by the percentage of successful (error-free) runs

Each list defaults to highest-to-lowest order. Click the sort icon to toggle the direction — useful when you want to surface your least-adopted or most error-prone integrations.

Spot adoption gaps. The Template Adoption list shows which integrations your end users are actually activating. If a template you've invested in isn't being picked up, that's a signal to revisit its description, positioning, or discoverability in the Hub.

Find reliability problems early. The Success Rate list is your fastest path to identifying broken or underperforming integrations. Sort lowest-to-highest to surface the most problematic ones and investigate via Logs.

Understand engagement trends. Active Users and Data Messages both include a 30-day delta, so you can see whether engagement is growing or declining without running any additional queries.

All metrics shown on this page are also available via the Appmixer REST API. If you're building custom dashboards or integrating Hub analytics into your own admin tooling, see the Analytics API reference for available endpoints.

Appmixer offers a REST API that mirrors the functionalities accessible through its UI. This API enables advanced customizations, additional automations, and scripting capabilities for enhanced integration flexibility.

The base URL for the Appmixer REST API varies according to your specific Appmixer tenant. Throughout this documentation, it is referred to as [TENANT_API_URL]. Replace it with the API URL of your tenant, for example:

• https://api-acme.appmixer.ai for newer hosted tenants,

• https://api.acme.appmixer.cloud for older hosted tenants,

• the API URL of your own installation in case of a Self-Managed Appmixer.

Similarly, [TENANT_STUDIO_URL] refers to the URL of your Appmixer Studio, for example https://acme.appmixer.ai or https://my.acme.appmixer.cloud, and [TENANT_BACKOFFICE_URL] to the URL of your Appmixer Backoffice, for example https://backoffice-acme.appmixer.ai or https://backoffice.acme.appmixer.cloud.

The majority of the Appmixer API endpoints require authentication using an access token associated with an Appmixer user account. Certain endpoints may require that this user to has the admin scope; specific requirements are detailed at each endpoint's documentation. To obtain a user's access token, sign in using the user's credentials:

On success, Appmixer returns a JSON object structured as follows:

Use the token in the Authorization header to authenticate your user to the Appmixer API. For example:

Find the full documentation to the REST API .

The REST API is also described by an specification. Import it into tools such as Postman, Insomnia or Swagger UI to explore the API, generate API clients in your programming language, or give AI agents a machine-readable description of the API. Set the tenantApiUrl server variable to your [TENANT_API_URL].

The Automation Hub embeddable widget combines these features for your end-users:

• Browse and start Automations pre-built by your team

• Customize pre-built Automations

• Manage Logs and Accounts for their Automations

As you customize the Hub options such as layout, design and automation categories (tabs), the embed code shown in the Settings page will dynamically change.

You can copy the code from the Settings page or use this example code:

in the dedicated documentation section.

GET [TENANT_API_URL]/config

Only returns the values that have been stored by the user through the API

POST [TENANT_API_URL]/config

This tutorial will guide you through the process of creating, testing, and publishing your first Automation Template:

• Build a template using the Appmixer no-code Studio.

• Parametrize your template by adding fields to gather information from your end-users through an easy-to-use web form (Wizard).

• Test the Automation Template

App Events provide the simplest method for sending data to Appmixer. To utilize App Events, select the OnAppEvent trigger from the Utilities category of connectors:

Assign a meaningful name to your app event and consider providing sample data. Although including sample data is optional, it facilitates referencing the data from the app event in subsequent components.

Providing an Event Data Example populates all detected JSON fields as variables in subsequent connected components. This allows you to easily use and reference these data placeholders throughout your integration, ensuring that the necessary information is accessible and can be dynamically incorporated into various parts of your workflow. This practice enhances the configurability and functionality of your automations by clearly mapping out how data flows between components.

Once your automation or integration templates are built, published, and users begin activating your integrations, you can trigger app events by using the appmixer.api.sendAppEvent(EVENT, DATA) function provided by the client-side Appmixer SDK. This function enables you to programmatically send events and associated data through your application, facilitating real-time interaction and response within your integrations.

When set to true, the component will not be visible to end users.

Set webhook property to true if you want your component to be a "webhook" type. That means that context.getWebhookUrl() method becomes available to you inside your component virtual methods (such as receive()). You can use this URL to send HTTP requests to. See the Behaviour section, especially the context.getWebhookUrl() for details and example.

Set state property to { persistent: true } to tell the engine not to delete component state when flow is stopped. See context.state for more information.

Components can use 3rd party libraries which are defined in the standard package.json file. An example:

{
    "name": "appmixer.twilio.sms.SendSMS",
    "version": "1.0.0",
    "private": true,
    "main": "SendSMS.js",
    "author": "David Durman <david@client.io>",
    "dependencies": {
        "twilio": "^2.11.0"
    }
}

The package.json file from the example above tells Appmixer to load the twilio library that the appmixer.twilio.sms.SendSMS component requires for its operation.

More information on the package.json file can be found at https://docs.npmjs.com/files/package.json.

By default, you can send GET, POST, PUT, or DELETE HTTP requests to a component. With the property httpRequestMethods you can define, which HTTP methods are allowed. Additionally, you can add support for the OPTIONS method:

{
    "name": "appmixer.utils.http.WebhookWithOPTIONS",
    "description": "Support for OPTIONS and POST",
    "webhook": true,
    "httpRequestMethods": [ "POST", "OPTIONS" ], 
    ...
}

The author of the component. Example:

{
    "author": "David Durman <david@client.io>"
}

Configuration of the quota manager used for this component. Quotas allow you to throttle the firing of your component. This is especially useful and many times even necessary to make sure you don't go over the limits of the usage of the API that you call in your components. Quota managers are defined in the quota.js file of your service/module. Example:

{
     "quota": {
        "manager": "pipedrive",
        "resources": "requests",
        "scope": {
            "userId": "{{userId}}"
        }
    }
}

Dynamic values

The {{}} can be used in any property within the quota definition. And values from two objects - the user's metadata, and the account's profileInfo can be used there. The following example shows how to dynamically select a resource based on the value of the user's metadata.tier .

{
     "quota": {
        "manager": "your-service",
        // Before the quota request is created, the system will check the user's
        // metadata.tier value. If set, it will be used as a 'resources' value.
        // If not, the value 'basic' will be used.
        "resources": "{{userMetadata.tier || 'basic'}}",
        "scope": {
            "userId": "{{userId}}"
        }
    }
}

The quota.js file with the rules for the previous example could look like this:

module.exports = {
    rules: [
        {
            name: 'basic-tier',
            limit: 10,          // 10 requests per minute
            window: 1000 * 60,  // 1 minute
            throttling: 'window-sliding',
            queueing: 'fifo',
            resource: 'basic',  // the 'basic' resource
            scope: 'userId'
        },
        {

            name: 'paid-tier',
            limit: 100,         // or 100 requests per minute
            window: 1000 * 60,  // 1 minute
            throttling: 'window-sliding',
            queueing: 'fifo',
            resource: 'paid',   // the 'paid' resource
            scope: 'userId'
        }
    ]
};

The other object that can be used here is the profileInfo.

{
     "quota": {
        "manager": "your-service",
        // Before the quota request is created, the system will check the user's
        // account profileInfo.tier value. If set, it will be used as a 'resources' value.
        // If not, the value 'basic' will be used.
        "resources": "{{profileInfo.tier || 'basic'}}",
        "scope": {
            "userId": "{{userId}}"
        }
    }
}

quota.manager

The name of the quota module where usage limit rules are defined.

One or more resources that identify rules from the quota module that apply to this component. Each rule in the quota module can have the resource property. quota.resources allow you to cherry-pick rules from the list of rules in the quota module that apply to this component. quota.resources can either be a string or an array of strings.

Dynamic values. Sometimes, different users have different quotas for the same service.

This scope instructs the quota manager to count calls either for the entire application (service) or per user. Currently, it can either be omitted, in which case the quota limits for this component apply to the whole application, or it can be { "userId": "{{userId}}" } . In this case, the quota limits are counted per Appmixer user. The last option is { "componentId: "{{componentId}}" }. In that case, the quota limits are counted per component.

Configuration

Set up a new instance with config parameters and set/get methods:

const storage = appmixer.ui.Storage(config)

storage.set(key, value)
storage.get(key)

config.el ...

config.storeId

Type: String | Default: []

ID of a store to open within the storage.

Instance

State

storage.state(name, value)

loader

Type: Boolean | Default: null

Toggle a custom loading state.

Type: String | Default: null

Toggle a custom error message.

The vast majority of API endpoints within the Appmixer require an access token to execute the calls. The following methods explain how to create a user and obtain the access token through the sign-in endpoint.

POST [TENANT_API_URL]/user/auth

Sign in a user with credentials and get their access token. curl -XPOST "https://api.appmixer.com/user/auth" -H "Content-type: application/json" -d '{ "username": "abc@example.com", "password": "abc321" }'

You can sign in either with your username and password or with your email and

All integration templates and automations are internally represented as flows. A flow consists of an orchestrated pattern of business activity enabled by interconnecting components together that transform input data (coming from trigger-type of components), perform actions, store data and/or load data to external systems.

Appmixer provides an interpreter for running flows and UI to manage flows.

Flows are represented as JSON objects in the Appmixer engine. The JSON object is called "flow descriptor" in the Appmixer jargon and for the example image above, it may look like this:

The flow descriptor contains information about the components in the flow and their types, how they are interconnected (source), their properties (config.properties) and data transformation for all input ports (config.transform).

Set up a new instance with config parameters and set/get methods:

Type: Boolean | Default: null

Toggle a custom loading state.

Type: String | Default: null

Set up a new instance with config parameters and set/get methods:

Type: Boolean | Default: null

Toggle a custom loading state.

Type: String | Default: null

Load appmixer.js UMD module in your HTML file:

See the following repositories for more comprehensive demos on how Appmixer can be embedded in your apps , .

Download appmixer.es.js ES module and include the files in your project:

Choose Appmixer UI widgets to include:

Refer to the getting started guide to get started quickly.

The marker icon that can be added to the component in the UI to give some extra context. The most common use case is to display e.g. a "Beta" badge to tell the user that this component is in beta. The marker must be in the Data URI image format as described here: . image/png or image/svg+xml image types are recommended. The marker icon is displayed in the top right corner of the component shape. Example:

Appmixer Backoffice is an administration UI for Appmixer. Use it to install, update and configure connectors, have an oversight of all the flows and users in Appmixer and set system configuration.

The Appmixer Backoffice is accessible via the "Admin" menu item in the Appmixer Studio:

This tutorial is designed to walk you through the process of building your first automation. Whereas integrations consist of predefined workflows that end-users can easily activate via a web form, automations are a powerful tool for enhancing your internal business operations. They allow you to link applications and services used within your organization or to launch bespoke business logic that meets your unique requirements.

Automation Overview

In this tutorial, we'll construct an automation designed to gather customer feedback via Typeform, relay each piece of feedback as a Slack notification, and automatically generate a GitHub issue based on the customer's response to the question: "What improvements or additional features would you like to see in future updates?". Utilizing OpenAI's ChatGPT, the generated ticket will be structured as a comprehensive user story, encompassing title, role, goal, reason, acceptance criteria, and test case.

Let's delve into the specifics of the automation flow:

Here's the first piece of customer feedback collected through our Typeform:

As a consequence, we received a notification in Slack:

Furthermore, a new GitHub Issue was created containing this content:

The upcoming sections will walk you through the steps required to build the aforementioned automation from start to finish.

Every automation begins with a trigger, which initiates the automation flow. Typically, triggers can capture data from external sources—like a Webhook trigger or a Gmail - New Email trigger—or they can be based on time events, such as a Scheduler or Timer. This setup allows you to program your automations to run at predetermined times, for instance, "every day" or "each week on Monday at 2pm". A unique trigger type is the "On Start" trigger, which activates immediately when your automation flow is started. This is particularly useful for batch operations that you intend to run only once or for debugging purposes.

To start building an automation, go to the Automations page and select "Create Automation". This will lead you to the Automation Designer. The first item you'll encounter there is the Trigger Selector. Look up "Typeform" and choose the "New Entry" trigger.

In the Configuration Inspector on the right, authenticate with Typeform and select one of your forms:

Click Add Step on the side of the New Entry trigger and find Slack. Pick the Send Channel Message action. Authenticate with your Slack account and select a Slack channel to direct your notifications:

Click the "+" button next to the Slack message field to include data placeholders for each Typeform question. These placeholders will be substituted with real data once the automation executes and retrieves customer feedback from Typeform:

Similarly, add the OpenAI - Send Prompt action. Configure the model, set the response type to json_object, and define the prompt as follows:

You can copy paste the prompt from here: From the below product feedback on improvements and additional features that was posted by a customer of our product Appmixer, create a user story for developers so that they have a concise description with a test case defining the feature. Format the user story as a JSON object with "title" and "content" properties. The "content" must contain a Github Markdown text with the following sections: "title", "role", "goal", "reason", "acceptance_criteria" and "test_case". Product feedback: <map your data variable from the form here>

The goal is to have ChatGPT generate a JSON comprising two fields: "title" and "content." This JSON will then be seamlessly integrated into the "Github.CreateIssue" action. The structure of our output JSON should resemble the following:

When your automation flow includes a component that outputs data you need to alter and then utilize the modified data across various configuration fields, employing the Control.SetVariable component proves beneficial. This component enables you to define custom variables, which can subsequently be referenced by name in other linked components. This approach is particularly advantageous when you aim to use transformed data in several locations, as it obviates the need to replicate the same modifications for a single variable across multiple fields.

In our scenario, we intend to capture the output of the ChatGPT completion (ChatGPT's response) in a variable named result. This allows us to conveniently reuse this data for both the title and description fields when we're ready to create our GitHub issue.

Given our interest in only the first choice, and considering that the message content of this choice is a JSON string (as specified in our prompt to ChatGPT), we need to manipulate the Choices variable to extract our desired JSON. To transform data within Appmixer, simply click on a variable to access the Modifiers panel and then sequentially apply the necessary modifiers, akin to how formulas are utilized in an Excel sheet. In our case, we will employ the sequence of modifiers: First Item -> JSON Path -> Parse. This sequence will allow us to select the first item from the Choices list, extract the message.content from this item, and finally parse the message.content into a JSON object for later use. It is crucial to note that ChatGPT outputs a JSON string, not a JSON object, necessitating the Parse modifier to convert the text into structured data.

The final step involves creating a GitHub Issue using the title and content (in Markdown) generated by our AI. Navigate through the interface to locate the GitHub connector, then drag and drop it onto the canvas. Select the "CreateIssue" action and assign response.title and response.content (the JSON fields generated by ChatGPT) to the corresponding fields within the "Github.CreateIssue" action. As an additional step, choose the "enhancement" label from the selection box to categorize our GitHub issues as enhancements.

The Designer renders flows with a redesigned diagram and a modern look, in both light and dark modes. If your canvas gets messy while building, click the Align Diagram button in the upper toolbar: the flow is re-arranged into a clean left-to-right layout and zoomed to fit. Only component positions change — connections and configuration stay untouched — and the alignment can be undone in a single step.

Before starting your automation, you can test it using the "Test flow" button in the upper toolbar. This runs the flow once so you can verify that each component behaves as expected without needing to start it live.

Once the test finishes, you can see the status of each component and preview its logs by hovering over the individual components on the canvas.

The test status notification also tells you what kind of data was used for the test:

• Real data from the trigger component, if it was available.

• Historical data from the logs, if no real data was found on the trigger component.

• Dummy data generated for the test, if neither real nor historical data was available.

Your automation is now set up and ready to be launched. Begin by giving it a distinctive name; this can be done by double-clicking on the default "New flow" title and renaming it to something more descriptive, like "Track Customer Feature Requests". To activate your automation, click the "Start flow" button located in the top right corner. You'll notice the log panel opens at the bottom displaying the initial log entry: "Flow started". As customer feedback starts coming in through our Typeform web form, the log panel will populate with entries detailing the actions taken within the flow. These logs provide insights into each component's input, the data transmitted between components, and the output generated, offering a comprehensive view of the automation's operation:

Clicking any log entry will reveal a panel that offers additional details.

You can edit a running automation without stopping it. When an automation is active, an "Edit" button appears in the upper toolbar. Clicking it creates a draft, where you can make changes and test them just like on any other flow. Once you're happy with the draft, click "Publish changes" to replace the active version with it.

In addition to editing via a draft, you can view and manage the active version, the draft, and other versions in the versioning panel. Open it by clicking the Versioning icon on the left side of the upper toolbar, next to the automation's name. From the versioning panel you can browse through previous versions, create new versions manually as snapshots of the current state, or restore a previous version.

Get Services Configuration

GET [TENANT_API_URL]/service-config

Get a list of stored configurations.

Query Parameters

GET [TENANT_API_URL]/service-config/:serviceId

Get the configuration stored for the given service.

POST [TENANT_API_URL]/service-config

Creates a new configuration for a service. The only required parameter on the payload is the serviceId. The rest of the payload can be any key/value pairs that will be the desired configuration for the service. For example: { "serviceId": "appmixer:google", "clientID": "my-global-client-id", "clientSecret": "my-global-client-secret" }

PUT [TENANT_API_URL]/service-config/:serviceId

Updates the stored configuration for the given service. The payload should contain the whole configuration, as the payload content will overwrite the configuration stored under the service.

DELETE [TENANT_API_URL]/service-config/:serviceId

Removes the configuration from the given service.

Appmixer includes a variety of ready-to-use connectors, with some being immediately operational while others necessitate user authentication with third-party systems (such as Slack, Gmail, Teams, and many others). This authentication process typically employs the OAuth 2 protocol.

Appmixer features an internal Authentication Hub, functioning as an authentication proxy, which simplifies the setup process by eliminating the need to register your own OAuth credentials with third-party services. This means all OAuth-based connectors offered by Appmixer are ready to use right out of the box. However, should you prefer to use your own OAuth credentials for enhanced customization or compliance reasons, you have the flexibility to do so. This can be done for all or selected connectors by specifying your OAuth credentials (clientId and clientSecret) as outlined below.

The Connector Configuration is available via the Appmixer Backoffice interface:

Custom OAuth Credentials

Appmixer offers several methods for configuring the OAuth credentials, with the Appmixer Backoffice being the simplest. For instance, if you're looking to use Slack components, you'll first need to register your application on the Slack developer portal, where you'll receive a clientId and clientSecret. After obtaining these, you can save them into Appmixer as follows:

For the Configuration ID, use appmixer:slack. You are now ready to add the Slack OAuth app clientId and clientSecret.

Add a key named clientId (it's crucial to use exactly clientId, not clientID or any other variation) and assign it the clientId you received from Slack.

Following that, add the clientSecret you received from Slack.

Once you've added the clientId and clientSecret, you're all set to utilize the Slack components within Appmixer.

A few connectors call third-party APIs with an API key provided by Appmixer, so your end-users can use them right away without connecting an account of their own. These keys are shared by every tenant, so the Appmixer engine enforces a usage limit on them. The limit applies per Appmixer tenant and is shared by all users and flows of that tenant.

When a limit is reached, the engine does not fail the flow. The holds the message in a queue and processes it once the time window allows, so the flow only slows down. The third-party API is never called beyond the limit. The exception is the Email connector, where the Appmixer Cloud e-mail service rejects requests above its hourly limit and the component reports an error.

If you need higher limits, you can switch any of these connectors to your own key. Create a Connector Configuration entry in the Backoffice (or via the ) with the Configuration ID and keys listed below. The connector picks the configuration up automatically, no re-installation is needed.

• Email (appmixer.utils.email, SendEmail). By default e-mails are sent through Appmixer's Mailchimp Transactional (Mandrill) account from no-reply@appmixer.com. Limit: 100 e-mails per hour, and 700 e-mails per day. Above 100 per hour the component fails with a rate-limit error and the engine retries the message later. Your own key: Configuration ID appmixer:utils:email, key apiKey set to your Mailchimp Transactional API key, and optionally fromEmail for the sender address. With your own key the e-mails are sent directly through your Mailchimp account and the hourly limit no longer applies.

• Weather

In scenarios where third-party developer consoles require the verification of domain ownership for domains used as callback URLs in OAuth-registered applications, you might face challenges (for example with configurations like the ). Given that your Appmixer tenant operates under the domain of your [TENANT_API_URL] and you lack access to this domain's DNS settings, your options for domain verification can seem limited.

To facilitate this process, the includes a tool designed specifically for domain verification purposes. This tool enables you to upload a file that the third-party service has generated for verification. Once uploaded, this file becomes accessible at the root of your domain. The third-party service verifies domain ownership by checking for the presence of this file at the specified root location on your domain, thus confirming that you indeed control the domain. This public file method provides a straightforward solution for verifying your Appmixer tenant domain without the need for DNS access.

To upload a public file to the root location, navigate to the Appmixer Backoffice interface and select the "System -> Public Files" option from the left menu. On this page, you'll find the functionality to upload your files.

Once you've uploaded your files through the Appmixer Backoffice, they will be accessible via your Appmixer Tenant API URL. For instance, if you upload a file named google52658022a92d779c.html, it can be accessed at [TENANT_API_URL]/google52658022a92d779c.html as well as at the well-known directory URL [TENANT_API_URL]/.well-known/google52658022a92d779c.html. This accessibility ensures that third-party services can easily verify domain ownership by locating the specified file at your domain's root or the well-known directory.

For customers managing their own Appmixer installations, there's flexibility to adjust where these public files are hosted through the PUBLIC_FILES_PREFIX system configuration option. This setting allows you to tailor the file access paths to suit your infrastructure requirements, providing further control over how you manage domain verification and public file accessibility.

Get ACL types

GET [TENANT_API_URL]/acl-types

There are two types of access control lists, for components and for API routes. Restricted to admin users only.

[
    "routes",

Get ACL rules for components|routes

GET [TENANT_API_URL]/acl/:type

Get list of all the ACL rules for given type. Restricted to admin users only.

POST [TENANT_API_URL]/acl/:type

Update ACL rule set for given type. Restricted to admin users only.

GET [TENANT_API_URL]/acl/:type/resources

Get available values for resource property for an ACL rule. This is used for building UI in Backoffice for setting ACL rules. Restricted to admin users only.

GET [TENANT_API_URL]/acl/:type/actions

Get available values for action property for an ACL rule. This is used for building UI in Backoffice for setting ACL rules. Restricted to admin users only.

GET [TENANT_API_URL]/acl/:type/resource/:resource/attributes

Get available values for attributes property for an ACL rules. This is used for building UI in Backoffice for setting ACL rules. Restricted to admin users only.

Fire patterns is an advanced configuration of a component that allows you to define when your component is ready to fire (ready to process input messages). Fire patterns can make the engine to hold input messages on components input ports until the pattern matches and then send the messages to the component in bulk. Fire patterns are defined as an array or a matrix. An example of fire patterns may look like this:

{
    "firePatterns": ['*', 1]
}

The fire pattern above is interpreted as follows: The component processes messages only if the first input port has zero or more messages waiting in the queue and at least one message waiting in the second input port queue. Another example can be a fire pattern:

{
    "firePatterns": [1, 1]
}

In this case, the component only processes messages if there is at least one message on each of its two input ports. A good example for this pattern is the Sum component:

The Sum component expects messages on both of its input ports before it can produce a sum of its inputs.

The following table lists all the possible fire pattern symbols:

Note that you can also define a set of fire patterns for a component, for example:

When more fire patterns are used, there must be at least one fire pattern that matches before the component fires.

Configuration

Set up a new instance with config parameters and set/get methods:

const files = appmixer.ui.Files(config)

files.set(key, value)
files.get(key)

config.el ...

Instance

State

files.state(name, value)

loader

Type: Boolean | Default: null

Toggle a custom loading state.

error

Type: String | Default: null

Toggle a custom error message. &#xNAN;query

Type: Object | Default: DefaultQuery

Defines custom query parameters for retrieving files. Example:

Triggered when the user selects a flow associated with a file listed in the widget.

The "Connectors" section of the interface shows all available connectors that you can manage, including options to install, update, or remove them. Connectors that are already installed will display an "Installed" badge at the top. Furthermore, you have the ability to search for connectors based on various criteria, such as their name or installation status, to easily find the ones you're interested in managing.

Clicking on any connector will redirect you to that connector's detailed page, where you can find more information and manage settings specific to that connector.

On the connector's detail page, you will find a comprehensive description of the connector, along with options to download the connector as a zip file, and to install, update, or remove the connector from your Appmixer tenant. Additionally, the page provides a list of the connector's components, including actions and triggers, complete with their respective descriptions. This information aids in understanding the functionality and potential use cases of each component within your workflows.

To install new connectors, simply click the "Install Connector" button found on the Connector details page.

Connectors in Appmixer are structured into "services", "modules" and "components" hierarchy. Each service can have multiple modules and each module can have multiple components. For example, "Google" service can have "gmail", "calendar" or "spreadsheets" modules and "gmail" module can have "SendEmail", "NewEmail" and other components:

This hierarchy is reflected in the directory structure of component definitions. Typically, services and modules are structured in two ways. Either the service itself appears as an "app" in Appmixer or modules are separate apps. If a module has its own manifest file (module.json), it is considered a separate app in Appmixer.

For example, in case of Google, we want to have separate apps for each module (GMail, Calendar, Analytics, ...):

But in case of Twilio, we may just want to have one app and all the actions/triggers as different components of the Twilio app:

POST /variables/:flowId/fetch

Get variables. Variables are placeholders that can be used in component config or inputs. These placeholders are replaced either at runtime by data coming from components connected back in the chain (dynamic variables) or by real values (static variables).

Headers

Set up a new appmixer instance with configuration parameters passed directly into the constructor or use the set/get methods:

Type: String | Default: null

Base URL of your Appmixer engine REST API.

Type: String | Default: null

Set up a new instance with config parameters and set/get methods:

Type: String | Default: null

The ID of a flow that is opened in the wizard.

Type: Boolean | Default: null

Set up a new instance with config parameters and set/get methods:

Type: Boolean | Default: null

Toggle a custom loading state.

Type: String | Default: null

Setting a custom API option

Custom API is represented as an object composed of asynchronous methods that you set on your Appmixer SDK instance using the api option:

var myCustomApi = {
  /* the key must match an existing API method */
  myCustomApiMethod(/* arguments of the original method */) {
    return new Promise((resolve) => {
      resolve(myCustomResponse);
    });
  }
}

/* Use a custom API on the entire SDK instance */
var appmixer = new Appmixer({ api: myCustomApi });

/* Use a custom API on a particular SDK UI widget */
var designer = new appmixer.ui.Designer({ api: myCustomApi });

The list of API methods can be found here.

An example how to redefine the flow update request.

Get Modifiers

GET [TENANT_API_URL]/modifiers

Get available modifiers. Appmixer is shipped by default with its own set of modifiers by default. Checkout this API to see what they are. You can then redefine the default set with the following API endpoint.

{
    "categories": {
        "object": {
            "label": "Object",
            "index": 1
        },
        "list": {
            "label": "List",
            "index": 2
        },
        ...

Edit Modifiers

PUT [TENANT_API_URL]/modifiers

Change the modifiers and their categories as a whole. Restricted to admin users only. Before editing existing modifiers or adding new ones, checkout the GET /modifiers API to see the structure.

DELETE [TENANT_API_URL]/modifiers

Delete all modifiers. Restricted to admin users only.

POST [TENANT_API_URL]/modifiers/test

This endpoint can be used to test a helper function with the desired arguments, to check how it will behave under different conditions. curl -XPOST "https://api.appmixer.com/modifiers/test" -H "Content-type: application/json" -H "Authorization: Bearer [ACCESS-TOKEN]" -d '{ "helperFn": "function(value) { return value && value.hasOwnProperty('\''length'\'') ? value.length : 0; }", "arguments": ["test"]}'

Get messages

GET [TENANT_API_URL]/unprocessed-messages

Get the list of the unprocessed messages for the current user.

Path Parameters

GET [TENANT_API_URL]/unprocessed-messages/:messageId

Get a single message.

DELETE [TENANT_API_URL]/unprocessed-messages/:messageId

Delete a message.

POST [TENANT_API_URL]/unprocessed-messages/:messageId

Put the message back into Appmixer engine.

Configuration

Set up a new instance with config parameters and set/get methods:

const insightsLogs = appmixer.ui.InsightsLogs(config)

insightsLogs.set(key, value)
insightsLogs.get(key)

config.el ...

config.flowId

ID of a flow to filter the logs by.

Instance

State

insightsLogs.state(name, value)

loader

Type: Boolean | Default: null

Toggle a custom loading state.

error

Type: String | Default: null

Toggle a custom error message. &#xNAN;filterLayout

Type: String | Default: 'expanded'

Controls whether the left filter panel is shown. Options: 'collapsed' or 'expanded'. Example: Set the initial state and toggle it programmatically at runtime.

query

Type: Object | Default: {}

The current query of the widget. Changing it reloads the logs table. Example: Retrieving the current query from the widget's state.

Set an initial query in the widget's state:

When modifying the query, always merge it with the current query object.

Listen for changes triggered by UI interactions:

You can directly read or set nested query properties using a /-separated path.

In the following sections, you'll learn how to build a support AI agent that can access your data—specifically, support tickets and details about your development teams, including their roles and the contact information of the team lead.

This AI agent can analyze support tickets (e.g., identifying the biggest pain points your customers faced in the past month) and take action—such as suggesting product improvements based on the most common issues and sending those suggestions to the relevant team lead responsible for that part of your application.

Sounds useful? Let’s build it!

To begin, we'll create a new workflow in Appmixer, our no-code AI agent builder.

‍

The first step is defining what will activate the agent. In this demo, we use a chat widget as the trigger, but you can also trigger the agent based on other events—for instance, new emails, new tasks, or scheduling the agent to run at a specific date and time.

Once the chat trigger is selected, Appmixer provides a chat URL and a chat script that allows you to integrate the chat widget into any web application

GET [TENANT_API_URL]/files/metadata/:fileId

Get the information for the specified file. Note that the file content is not included.

The majority of APIs define limits on the API usage. Components that call APIs need to make sure that these limits are respected, otherwise their API calls would start failing quickly. The quota.js module allows you to specify what those limits are on a per-service, per-module or even per-component basis. The Appmixer engine uses this module to make sure API calls are throttled so that the usage limits are respected.

The quota module must be named quota.js and must be stored under either the service, module or component directory (i.e. [vendor]/[service]/quota.js , [vendor/[service]/[module]/quota.jsor [vendor/[service]/[module]/[component]/quota.js.

An example of a quota module:

The quota definition above tells the engine to throttle the

A strings object is represented as a JSON object that you set on your Appmixer SDK instance using the set('strings', myStrings) method:

If you don't set strings, the default strings will be applied.

The strings object is a JSON object (with one exception, see below) that contains references to various UI elements within the Appmixer UI. The final values of the JSON objects are the actual strings used in the UI.

Example of setting the strings object:

For reference, we prepared a complete strings object for you to download and inspect to see all the possibilities for strings customization/localization.

For localization of time-related strings, a special time root scope of the strings object can be modified: