The Action Provider service plugin (formerly SPI) allows you to implement an action that site contributors can add to automations on their sites. This means you can take actions in your service in response to events that happen on Wix sites or in the business manager. For example, in response to a trigger, your service can send an email, generate an invoice, or update another Wix service using its APIs.
The Action service plugin lets you do the following:
To configure your action in your app's dashboard:
Select Automations from the left menu, then select Create New > Action.
Give your action a name. This is displayed to users when they add the action in the Automations UI.
Notes:
Add a short description explaining what your action does. The description is displayed to users when they select your action. This is an optional field.
Choose whether to hide the action, so it doesn't appear as an individual action on a user site. You should do this if the action is part of a pre-installed automation.
Under Action's service plugin endpoints, enter your base provider URI and select the service plugin endpoints you intend to implement.
Configure your input schema.
Optionally, configure your action's UI.
Click Save at the top of the page in order to save your action.
Next, you need to test your action to make sure everything's working. You can install your app on a free Premium development site to test it.
Once you create the test site, return to your app's dashboard and click Test Your App > Dashboard. Select the test site you installed your app on earlier. Use this site to make sure your action is working.
When you have tested your app and are ready to publish your new action, submit your app for review. A member of our team will check the changes and approve the latest version.
Once our team has approved your app, it will be published and available for users to install on their sites. When a user installs your app, your actions become available for their automations, as shown here:
When an automation is triggered, Wix passes data from the trigger payload to your service so it can perform your action. You tell Wix exactly what data your action requires by defining the input schema. The input schema is a JSON Schema that allows you to define the data types your action needs. You must provide the input schema when you configure your action in your app's dashboard.
If the trigger payload fields do not match the fields in your input schema, your action will not run when the automation is triggered.
See the tables below for the expected input schema structure.
Tip: To create a starter schema using sample values and required properties, use the Generate from Sample Data option. You can then fill in the rest of the schema as needed.
These properties are at the schema's root level.
The input schema supports schema composition keywords such as allOf
, anyOf
, and oneOf
.
Important: Wix does not validate breaking changes to an input schema that uses composition. To ensure the user does not make errors when configuring an action that uses composition in its schema, we recommend performing the validation on your end.
Property | Data Type | Description |
---|---|---|
$schema | string | When you save the action configuration, Wix overrides this property to set it to "http://json-schema.org/draft-07/schema" . |
type | string | Required. Must be "object" . |
properties | object | Required. Object containing the key-object pairs that define the fields in the action configuration. See the properties object below for details. |
required | array | List of property keys that must be provided to the action. In the action configuration UI on the user's site, these will be marked as required fields. |
additionalProperties | boolean | When you save the action configuration, Wix overrides this property to set the value to true , which allows additional, unspecified properties to be sent in the payload. |
properties
objectThe properties
object contains the key-object pairs that make up the bulk of the data passed to the action. The key name can include only alphanumeric characters or underscores (A-Z, a-z, 0-9, _). It cannot start with an underscore.
Each paired object contains display and validation metadata. This table gives the expected data structure for an object in properties
:
Property | Data Type | Description |
---|---|---|
type | string | Required. Supported values: "string" , "number" , "integer" , "boolean" , "array" , "object" .Expected data type of the payload property. See the input schema Storybook for more details about each type. |
title | string | Required. Display name for the property. Shown to users when they create or edit an automation. |
examples | array | Example values, displayed as placeholders when users test certain automation actions. Must be the same data type defined in type . |
format | string | Validated string format. Used only when type is "string" . See built-in formats (from the JSON Schema 2020-12 docs) for supported formats.If set to "uuid" , the property can be connected to a site's contacts. |
identityType | string | Supported values: "contact" , "member" , "visitor" .If you add this property to the input schema, the action becomes available for triggers that use contactID , and its icon appears in the list of actions available when such a trigger is selected. If you do not add this property, the action is not available for these triggers and does not appear in the possible list of actions. Max: 1 payload property. |
items | object | Required if type is "array" . Omitted for other data types. Object that contains array metadata. See the items object below for details. |
oneOf | array | Creates a field that lets a user select one from multiple options. See the oneOf object below for details. |
properties | object | Required if type is "object" . Omitted for other data types.Contains key-object pairs that define the properties of the nested object. Accepts the same data as the 1st-level properties object and may contain strings, numbers, integers, booleans, or nested objects. |
required | array | Used only when the type is "object" or "array" . List of property keys that must be provided to the action service. |
uniqueItems | boolean | Used only when the type is "array" . Allows a field to be added only once to the action configuration UI. |
items
objectitems
is an object that contains an array schema.
Property | Data Type | Description |
---|---|---|
type | string | Required. Defines the expected data type of the array. |
properties | object | Required if type is "object" . Contains key-object pairs that define the properties of the array objects. Accepts the same data as the 1st-level properties object, but can contain only strings, numbers, integers, or booleans. |
required | array | Used only when the type is "object" . List of property keys that must be provided to the action service. |
oneOf
objectoneOf
is an array of objects. It defines a field in which a user can choose one of multiple options.
Property | Data Type | Description |
---|---|---|
type | string | Required. Defines the expected data type of the option. Must match the parent type defined for the entire field. |
title | string | Required. The option value displayed to users. This value can be translated into another language. |
const | varies | Required if type is "string" . Strings must be in English. The option value that is sent to the backend for validation. |
description | string | Provides more information about an option. This value can be translated into another language. |
Once you publish the action with your app, Wix enforces the following limits on changes you can make to the action's input schema. Once the action is saved, you can't:
As an action provider, you can enforce limits on the number of times a site owner uses an action. For example, an action provider can limit the number of messages a user can send per billing cycle. You can enforce different quotas on specific features of the app, depending on the user. For example, your app might have a basic plan that allows the user to send 500 emails a month, and a premium plan that lets the user send unlimited emails.
quota: A limit on the number of times a site owner can perform an action. For example, you can set a quota of 500 reminder emails that the user may send.
plan: Allows you to set different quotas for different users.
You are responsible for enforcing quotas for features used by their actions. If the features provided by your service have quotas you can implement the Get Action Quota Info endpoint so that Wix can display your quotas in the user's site dashboard. Wix displays the quotas in the Manage your automations quotas modal. This modal opens when site contributors click the Manage Your Quotas button on the Automations page in the dashboard.
The modal lists the quotas for all the features used by the site's automations. The list is organized by the apps providing the features.
You can define the different elements of each quota display in the responses from your Get Action Quota Info endpoint. In general, each quota display includes a plan, and the plan features associated with it. The current usage and limit for each feature is displayed.
To display one plan with a single feature quota, include the plan and quota data in the same quotaInfo
object in your endpoint’s response.
Sample response body:
{
"enforced": true,
"quotaInfo": [
{
"plans": [
{
"id": "fdc7fe4b-523f-4d8c-b6e1-5faf3850d01e",
"name": "Reminder emails"
}
],
"quotas": [
{
"featureName": "Reminders sent",
"currentUsage": "10",
"limit": "40"
},
{
"featureName": "Tasks created",
"renewalDate": "2022-01-12T01:20:00.000Z",
"currentUsage": "346",
"limit": "500"
}
],
"upgradeCta": {
"url": "https://www.example.com/upgrade",
"label": "Upgrade For More"
}
}
]
}
The resulting quota display looks like this:
To display one plan with a single feature quota, include the plan and quota data in the same quotaInfo
object in your endpoint’s response.
Sample response body:
{
"enforced": true,
"quotaInfo": [
{
"plans": [
{
"id": "f32c650f-ecc4-4818-a81c-8fa681e325a6",
"name": "Email Marketing"
}
],
"quotas": [
{
"featureName": "Emails sent",
"currentUsage": "346",
"limit": "500",
"renewalDate": "2023-01-12T01:20:00.000Z"
}
],
"upgradeCta": {
"url": "https://www.example.com/upgrade",
"label": "Upgrade Email Plan"
}
}
]
}
The resulting quota display should look something like this:
To display two different plans with different features that are both being used by your action service, include two quotaInfo
objects in your response body.
Sample response body:
{
"enforced": true,
"quotaInfo": [
{
"plans": [
{
"id": "94e55e1f-b845-47a5-afad-4b8fc977d545",
"name": "Forms on your site"
}
],
"quotas": [
{
"featureName": "Forms on your site",
"currentUsage": "6",
"limit": "40"
}
],
"upgradeCta": {
"url": "https://www.example.com/upgrade",
"label": "Upgrade For More",
"planId": "fd9830b5-ce89-495f-87e8-30893168afd9"
}
},
{
"plans": [
{
"id": "c7f255a5-0aa2-47ad-9607-8f87ea56df5b",
"name": "Code Forms on your site"
}
],
"quotas": [
{
"featureName": "Code Forms on your site",
"currentUsage": "1",
"limit": "20"
}
],
"upgradeCta": {
"url": "https://www.example.com/upgrade",
"label": "Upgrade For More",
"planId": "b19345c1-380c-4fc6-8e45-9f7f72b3de5f"
}
}
]
}
The resulting quota display looks like this:
If your service supports a plan where features are unlimited, you can still display the site contributor’s current usage. To do this, provide a quotaInfo
object with the relevant plan details. Include the feature’s name and current usage, but not a usage limit.
Sample response body:
{
"enforced": true,
"quotaInfo": [
{
"plans": [
{
"id": "1ccaa3a5-4994-4e17-b1d4-2fa3f76418e7",
"name": "Marketing Emails"
}
],
"quotas": [
{
"featureName": "Emails",
"currentUsage": "150"
}
]
}
]
}
The resulting quota display should look like this:
If your service enforces a quota on a feature that a site contributor hasn’t paid for, you can display this in the dashboard. This lets the site contributor know that your action isn’t running when their automation is triggered. To display this, set both the current usage and limit for the feature to 0
in the relevant quotaInfo
object in your response body.
Sample response body:
{
"enforced": true,
"quotaInfo": [
{
"plans": [
{
"id": "d0a9fa93-f2a7-426a-89d6-a15d2e7c0d78",
"name": "Marketing Emails"
}
],
"quotas": [
{
"featureName": "Monthly Emails",
"renewalDate": "",
"currentUsage": "0",
"limit": "0"
}
],
"upgradeCta": {
"url": "https://www.example.com/upgrade",
"label": "Upgrade",
"planId": "28d52c9c-7c59-4a14-bbc1-a7d9103e1038"
}
}
]
}
You can define a tooltip that provides more details about a feature quota. To display the tooltip, add an additionalInfo
object together with the feature details.
Sample response body:
{
"enforced": true,
"quotaInfo": [
{
"plans": [
{
"id": "fa9bbb78-286f-46b4-83fe-4aa81d94c715",
"name": "Marketing Messages"
}
],
"quotas": [
{
"featureName": "SMS sent",
"renewalDate": "",
"currentUsage": "400",
"limit": "1200",
"additionalInfo": {
"description": "Your SMS quota will renew each month. Any remaining messages won't roll over to the next month.",
"cta": {
"url": "/home",
"label": "Go to SMS Settings"
}
}
}
],
"upgradeCta": {
"planId": "e15d2206-4226-4815-8684-41b101c7dcad",
"url": "https://www.example.com/upgrade",
"label": "Upgrade"
}
}
]
}
You should now see a message when you hover over the tooltip icon:
This endpoint is used to validate the user's action configuration.
Wix calls this endpoint when a site contributor configures an automation with your action, and when they select the automation from the Your automations list in the Automations dashboard. Wix uses the returned response to display an error message to a site contributor if the action is invalid.
Implementing this endpoint is optional. To implement it, select the endpoint under Action's service plugin Endpoints when editing your action in the app dashboard. If you don't implement this endpoint, Wix assumes that the action is always valid.
As an example, a user configures an action called “Send gift card”, where a gift card is identified by a unique UUID. After some period of time the user deletes the gift card, making the action’s mapping with the current UUID invalid. Validate Configuration checks the validity of the action’s input values, and returns an error to the user if one or more of the values is not valid.
Action key as defined in your app's action configuration in the app dashboard.
For example, send-email
or generate-invoice
.
Stringified object representing the mapping a site contributor made between keys in the input schema and their expected values when running the automation. A field can be a static value mapping, or an expression that will be evaluated dynamically on each activation.
Whether the action configuration is valid.
Error details for an invalid action configuration. These are the errors displayed to the user.
Validate Configuration request with a sample response body
curl -X POST https://provider.example.com/v1/validate-configuration \
-H 'user-agent: Wix' \
-H 'accept-encoding: gzip, deflate' \
-H 'content-type: text/plain; charset=utf-8' \
-d '{
"actionKey": "email-client",
"inputMapping": "{
\"accountId\": \"some guid\",
\"to\": \"some-email@example.com\",
\"subject\": \"Welcome email\",
\"body\": \"Hello there!\"
}"
}'
{
"valid": false,
"configurationErrors": [
{
"fieldKey": "accountId",
"message": "accountId does not exist",
"ctaLabel": "Create an account",
"ctaUrl": "https://www.example.com/create-account",
"title": "Account not found."
}
]
}
This endpoint retrieves quota information for an action.
Wix calls this endpoint when a site contributor opens the Manage your automations quotas modal in the Automations dashboard. The response from this endpoint is displayed in the modal. The data is displayed based on the response body format. Learn more about quota display options.
Implementing this endpoint is optional. To implement it, select the endpoint under Action's service plugin Endpoints when editing your action in the app dashboard.
Notes:
Action key as defined in your app's action configuration in the app dashboard.
For example, send-email
or generate-invoice
.
Details about the quotas for your action.
Get Quota Info request with a sample response body
curl -X POST https://provider.example.com/v1/quota-info \
-H 'user-agent: Wix' \
-H 'accept-encoding: gzip, deflate' \
-H 'content-type: text/plain; charset=utf-8' \
-d '{
"actionKey": "email-client",
}'
{
"enforced": true,
"quotaInfo": [
{
"plans": [
{
"id": "email-marketing-1w23e-1ww34",
"name": "Email Marketing"
}
],
"quotas": [
{
"featureName": "Emails sent",
"currentUsage": "346",
"limit": "500",
"renewalDate": "2023-01-12T01:20:00.000Z"
}
],
"upgradeCta": {
"url": "some link to upgrade",
"label": "Upgrade Email Plan"
}
}
]
}
This endpoint is used to invoke an action provider's action.
Wix calls this endpoint when an automation using the provider's action is triggered. The request body includes all the data needed to execute the action including the final values of any dynamic parameters.
There is no need to validate the data in the request body against the JSON schema defined when the action was configured. Wix validates the data before calling this endpoint.
Data for executing your action. Structured according to the input schema you provided when configuring the action in your app's dashboard.
Action key as defined in your app's action configuration in the app dashboard.
For example, send-email
or generate-invoice
.
If the action has no output schema, return an empty object. If the action defines an output schema, return a JSON object that correlates to the output schema.
Invoke request with a sample response body
curl -X POST https://provider.example.com/v1/invoke \
-H 'user-agent: Wix' \
-H 'accept-encoding: gzip, deflate' \
-H 'content-type: text/plain; charset=utf-8' \
-d '{
"actionParams": {
"to": "my@email.com",
"subject": "Your registration to 2022 Event is Confirmed",
"body": "Hi Jane, you are confirmed for the event"
},
"actionKey": "email-client"
}'
{
"result": {}
}