Documentation
Glossary
Action
In a Miix, the action is the work that Qmiix initiates as a result of an updated trigger.
Actions are organized under apps. Some example actions are “Create post” or “Post a new tweet”. Apps do not need to have both triggers and actions. Some apps will have only one or the other.
Action essential
When a user sets up a Miix, they populate the action’s “action essentials” with data, usually including elements provided by the trigger. Think of action essentials as a form field. For example, when using the “Create post” action, the two action essentials are for the “Title” and “Post Body”. When using the “Post a new tweet” action, the only action essential is the text of the message.
Almost every action has at least one action essential.
Miix
We bring apps together into Miixes. A Miix connects two or more apps or devices together. It enables you to do something that those apps or devices couldn’t do on their own.
Some example Miixes include Sync Amazon Alexa to-dos with your Google Calendar or Create events in your iPhone Calendar, via Google Assistant. Qmiix users can turn on Miixes that have been created by apps or other users, or they can create their own. Here’s a short video tutorial that shows you how to connect your apps and devices, and turn on Miixes.
Miixes are composed of triggers and actions. Triggers tell a Miix to start, and actions are the end result of a Miix run.
Miix ID
The Miix ID is an ID that specifies a Miix on Qmiix. For example, this Miix's ID is YfkYtQB2.
Miix defaults
See Miix templates in the API reference documentation.
Miix run
When a user sets up a Miix, Qmiix starts monitoring the endpoint specified by the trigger service. Every time Qmiix finds that the data has been updated, Qmiix will execute the Miix, pushing the data from the trigger over to the action(s). This is a “Miix Run”.
To get a Miix to run as close to the triggering event as possible, triggers should use the Realtime API.
OAuth Endpoint
OAuth endpoints (authorization url and token url) are used for OAuth2 user authentications for the app. Note that OAuth endpoints and app endpoints(see below) might not be the same domain or even owned by different legal entities. Therefore, for partner apps as a proxy to actual service provider, the OAuth endpoints should be the same as actual service providers. For example, for gmail partner app, the app endpoint prefix might be https://gmail.qmiix.com, while the OAuth endpoints would be https://accounts.google.com/o/oauth2/auth and https://accounts.google.com/o/oauth2/token.
App Endpoint
The URI at the partner app's domain where Qmiix will request updates (for triggers), validations (for dynamic validations), options (for dynamic options), user information, app status or POST data (for actions) or POST/DELETE trigger_identity (for starting or ending monitor of events). Endpoint required are trigger, action, validations, options, user information and app status. State endpoints are optional. Note that there might be more management webhooks endpoints required for partner app.
Elements
Each trigger contains elements – individual pieces of data.
Some example elements from the “New tweet by you” trigger from the Twitter app:
Text – The tweet itself.
UserName – User name of tweeter.
LinkToTweet – The URL to the tweet itself.
CreatedAt – Date and time tweet was created.
TweetEmbedCode – The HTML embed code for the Tweet.
A user will take the individual elements provided by a trigger and will use them to fill in an action’s action essentials.
Realtime API
Qmiix’s Realtime API lets Miixes using your triggers to run near-instantly. Utilizing the Realtime API is required for apps with triggers.
Public Management APIs
Qmiix provides sets of public management API for partner app. These APIs are public accessible to partner apps with rate limit.
Service providers
Service providers provide users features and services fulfilling their needs. Some example service providers are Twitter, Email, Facebook, Google Drive, and SMS.
Partner App
Apps are the basic building blocks of Qmiix providing webhooks for Qmiix to poll for triggers and call for actions. Partner apps might be service providers providing actual services to users or act as a proxy receiving requests from Qmiix, unwrapping requests and proxy the requests to actual service providers, wrapping the response from service providers, and proxy the responses to Qmiix.
Slug
In the context of the Qmiix platform, a slug is the immutable ID of an app, trigger, trigger essential, element, action, or action essential.
Trigger
In an Miix, the trigger is the data that, when changed, prompts an Miix to run on Qmiix. Some example triggers include, Breaking news for sport or New results from search.
Triggers are organized under apps. Each app provides an endpoint for each trigger, which is checked after the app POSTs to the Realtime API (recommended) alerting Qmiix that there is fresh trigger data. If the Realtime API is not used, the trigger is checked periodically for new data.
Apps do not need have to have both triggers and actions. Some apps will have only one or the other.
Trigger Essential
When a user builds or turns on a Miix, they can specify certain parameters that Qmiix will pass to the app's endpoint when it makes the request for new data.
Think of trigger essentials as a “filter” for the data requested from a trigger. For example, on the ESPN service, the “Breaking news for sport” has the trigger essential “Sport”. When the user sets up a Miix with that trigger, she can select which sport she’s interested in. Or for the Craigslist “New results from search” trigger, the user can specify the URL of the specific search they want.
Trigger Identity
A trigger_identity field is sent with every trigger endpoint request and can be thought of as unique signature of a specific user, trigger, and trigger essentials. For example, if a user has multiple Applets with the same trigger essentials/values they will each have the same trigger_identity.
