Ecwid Authenticate a Connector

You can authenticate with Ecwid to create your instance of the Ecwid connector through the UI or APIs. Once authenticated, you can use the connector instance to access the different functionality offered by the Ecwid platform.

Authenticate Through the UI

Use the UI to authenticate with Ecwid and create a connector instance. If you authenticate with Ecwid via OAuth 2.0, all you need to do is add a name for the instance, whereas authenticating via custom authorization will require you to input your Ecwid Store ID, Oder API Secret, and Product API Secret you recorded in API Provider Setup. After you create the instance, you'll log in to Ecwid to authorize Axway AMPLIFY to access your account. For more information about authenticating a connector instance, see Authenticate a Connector Instance (UI)

After successfully authenticating, we give you several options for the next steps. Make requests using the API docs associated with the instance, map the instance to a virtual data resource, or use it in a formula template.

Authenticate Through API

To provision your Ecwid connector, use the /instances API.

Call the /instances API

  • HTTP Headers: Authorization- User, Organization
  • HTTP Verb: POST
  • Request URL: /instances
  • Request Body: Required – see below
  • Query Parameters: none

Ecwid now has two types of authentication- Oauth2 or custom.


curl -X GET \
'<key>&apiSecret=<secret>&callbackUrl=<callback>' \

Authenticating Users and Receiving the Authorization Grant Code

Provide the oauthUrlin the response from the previous step to the users. After users authenticate, provides the following information in the response:

  • code
  • state
Response Parameter Description
code The authorization grant code returned from the API provider in an OAuth 2.0 authentication workflow. Axway AMPLIFY uses the code to retrieve the OAuth access and refresh tokens from the endpoint.
state A customizable identifier, typically the connector key (``).

If the user denies authentication and authorization, there will be a query string parameter called error instead of the code parameter. In this case, your application can handle the error gracefully.

Authenticating the Connector Instance

Use the code from the previous step and the /instances endpoint to authenticate with and create a connector instance. If you are configuring events, see the Events section.


The endpoint returns a connector instance token and id upon successful completion. Retain the token and id for all subsequent requests involving this connector instance.

To authenticate a connector instance:

  1. Construct a JSON body, as shown below (see parameters):

      "element": {
        "key": ""
      "providerData": {
        "code": "<AUTHORIZATION_GRANT_CODE>"
      "configuration": {
        "oauth.api.key": "< app >",
        "oauth.api.secret": "< app >",
        "oauth.callback.url": "< app  >"
      "tags": [
      "name": "<INSTANCE_NAME>"
  2. Call the following, including the JSON body you constructed in the previous step:

    POST /instances

    Make sure that you include the User and Organization keys in the header.

  3. Locate the token and id in the response and save them for all future requests using the connector instance.

Example Request

curl -X POST \ \
  -H 'authorization: User <USER_SECRET>, Organization <ORGANIZATION_SECRET>' \
  -H 'content-type: application/json' \
  -d '{
  "element": {
    "key": ""
  "providerData": {
    "code": "xxxxxxxxxxxxxxxxxxxxxxx"
  "configuration": {
    "oauth.api.key": "Rand0MAP1-key",
    "oauth.api.secret": "fak3AP1-s3Cr3t",
    "oauth.callback.url": "https;//",
  "tags": [
  "name": "API Instance"

Custom Authentication

To create an Ecwid instance with custom Authentication (note this is a legacy version of Ecwid so if you do not already have your store ID, order API Key, and Product API Key you should use oauth2), you will need the Store ID, Order API Key, and Product API Key. For instructions on how to retrieve those credentials, please see our Ecwid Endpoint Setup.


Ecwid currently supports the GET, PUT/PATCH, DELETE API calls. POST is not available at this time.

Description: Token is returned upon the successful execution of this API. This token needs to be retained by the application for all subsequent requests involving this connector instance.

A sample request illustrating the /instances API is shown below.

HTTP Headers:


This instance.json file must be included with your instance request. Please fill your information to provision. The “key” into Axway AMPLIFY Ecwid is “ecwid”. This will need to be entered in the “key” field below, depending on which Connector you wish to instantiate.

  "element": {
    "key": "ecwid"
  "configuration": {
    "ecwid.order.key": "<INSERT_API_ORDER_SECRET>",
    "ecwid.product.key": "<INSERT_API_PRODUCT_KEY>",
    "": "<INSERT_STORE_ID>"

Here is an example cURL command to create an instance using /instances API.

Example Request:

curl -X POST
-H 'Authorization: User <INSERT_USER_SECRET>, Organization <INSERT_ORGANIZATION_SECRET>'
-H 'Content-Type: application/json'
-d @instance.json

If a user does not specify a required config entry, an error will notify them of which entries are missing.

Below is a successful JSON response:

  "id": 12345,
  "name": "test",
  "token": "dsPr6AheLIS8pt7rp8E81bSKEkx9Ftr+9Y",
  "element": {
    "id": 42,
    "name": "Ecwid",
    "key": "ecwid",
    "description": "Ecwid is everything you need to sell anywhere.",
    "image": "elements/provider_ecwid.png",
    "active": true,
    "deleted": false,
    "typeOauth": false,
    "trialAccount": false,
    "configDescription": "If you do not have a Ecwid account, you can create one at Ecwid Signup"
  "provisionInteractions": [],
  "valid": true,
  "disabled": false,
  "maxCacheSize": 0,
  "cacheTimeToLive": 0,
  "cachingEnabled": false

Make sure you have straight quotes in your JSON files and cURL commands. Please use plain text formatting in your code.

Instance Configuration

The content in the configuration section or nested object in the body posted to the POST /instances or PUT /instances/{id} APIs varies depending on which connector is being instantiated. However, some configuration properties are common to all connectors and available to be configured for all connectors. These properties are -

  • event.notification.enabled: This property is a boolean property and determines if event reception (via webhook or polling) is enabled for the connector instance. This property defaults to false.
  • event.vendor.type: When the event.notification.enabled property is set to true, this property determines the mechanism to use to receive or fetch changed events from the service endpoint. The supported values are webhook and polling. Most connectors support one mechanism or the other, but some like support both mechanisms. This property is optional.
  • event.notification.type: This property can be used to determine how an event notification should be sent to the consumer of the connector instance, in most cases, your application. Currently, webhook is the only supported value for this property. This means that when an event is received by the connector instance, it will get forwarded to the provided event.notification.callback.url via a webhook to you. This property is optional.
  • event.notification.callback.url: As mentioned above, the value of this property is an http or https URL to which we will post the event for consumption by your application. This property is optional.
  • filter.response.nulls: This property defaults to true; in other words, its boolean property, and determines if null values in the response JSON should or should not be filtered from the response returned to the consuming application. By default, all null values are filtered from the response before sending the response to the consuming application.

Related Links