To provision your Ecwid Element, use the /instances API.
Ecwid now has two types of authentication- Oauth2 or custom.
curl -X GET \
'https://api.cloud-elements.com/elements/api-v2/elements//oauth/url?apiKey=<key>&apiSecret=<secret>&callbackUrl=<callback>' \
Provide the oauthUrl
in the response from the previous step to the users. After users authenticate, provides the following information in the response:
Response Parameter | Description |
---|---|
code | The authorization grant code returned from the API provider in an OAuth 2.0 authentication workflow. Cloud Elements uses the code to retrieve the OAuth access and refresh tokens from the endpoint. |
state | A customizable identifier, typically the element key (``) . |
error
instead of the code
parameter. In this case, your application can handle the error gracefully.
Use the code
from the previous step and the /instances
endpoint to authenticate with and create an element instance. If you are configuring events, see the Events section.
To authenticate an element instance:
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": [
"<Add_Your_Tag>"
],
"name": "<INSTANCE_NAME>"
}
Call the following, including the JSON body you constructed in the previous step:
POST /instances
Locate the token
and id
in the response and save them for all future requests using the element instance.
curl -X POST \
https://api.cloud-elements.com/elements/api-v2/instances \
-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;//mycoolapp.com",
},
"tags": [
"Docs"
],
"name": "API Instance"
}'
In order 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, adn 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. NOTE: Ecwid currently supports the the GET, PUT/PATCH, DELETE API calls. POST is not available at this time.
Description: An Element token is returned upon successful execution of this API. This token needs to be retained by the application for all subsequent requests involving this element instance.
A sample request illustrating the /instances API is shown below.
HTTP Headers:
Authorization: User <INSERT_USER_SECRET>, Organization <INSERT_ORGANIZATION_SECRET>
This instance.json file must be included with your instance request. Please fill your information to provision. The “key” into Cloud Elements Ecwid is “ecwid”. This will need to be entered in the “key” field below depending on which Element you wish to instantiate.
{
"element": {
"key": "ecwid"
},
"configuration": {
"ecwid.order.key": "<INSERT_API_ORDER_SECRET>",
"ecwid.product.key": "<INSERT_API_PRODUCT_KEY>",
"ecwid.store.id": "<INSERT_STORE_ID>"
},
"name": "<INSERT_INSTANCE_NAME>"
}
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
'https://api.cloud-elements.com/elements/api-v2/instances'
If the user does not specify a required config entry, an error will result notifying her of which entries she is 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
}
Note: Make sure you have straight quotes in your JSON files and cURL commands. Please use plain text formatting in your code.
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 element is being instantiated. However, some configuration properties are common to all elements and available to be configured for all elements. 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 element instance. This property defaults to false.event.vendor.type
: When event.notification.enabled
property is set to true, this property determines the mechanism for Cloud Elements to use to receive or fetch changed events from the service endpoint. The supported values are webhook
and polling
. Most elements support one mechanism or the other, but some elements, e.g., Salesforce.com 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 element 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 element 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 Cloud Element will post the event for consumption by your application. This property is optional.filter.response.nulls
: This property defaults to true, i.e., it's 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.