The API endpoints are developed around RESTful principles secure via the OAuth2.0 protocol.

Beyond the entry points, the API also provides a line of communication into your system via webhooks.

For testing purposes, we offer a staging environment. Also, more detailed information about the business rules and workflows can be found on the Documentation Section

Each API is versioned individually, but we follow these rules:

• Non breaking changes (eg: adding new fields) are added in the current version without previous communication
• Breaking changes (fields removal, semantic changed or schema update) have the version incremented
• Users will be notified about new versions and will be given time to migrate (the time will be set on a case by case basis)
• Once users migrate to the new version, we will deprecate the old ones
• Once there is a new version for an API, we won't accept new integrations targeting old versions

The APIs use resource-oriented URLs communicating, primarily, via JSON and leveraging the HTTP headers, response status codes, and verbs.

To exemplify how the API is to be consumed, consider a fake GET resource endpoint invocation below:

curl --request GET 'https://{{public-api-url}}/v1/resource/123' \
--header 'Authorization: Bearer 34fdabeeafds=' --header 'X-Store-Id: 321'

All resource endpoints expect the Authorization header, the remaining headers are explicitly stated in the individual endpoint documentation section.

With these headers, the system will:

• Validate the client token, making sure the call is originating from a trusted source.
• Validate that the Application has the permission to access the v1/resource/{id} resource via the Application's pre-configured scopes.
• Translate your X-Store-Id to our internal store ID (e.g. AAA).
• Validate and retrieve resource AAA, that is associated to your Application via store id 321.

POST/PUT methods will look similar to the GET calls, but they'll take in a body in the HTTP request (default to the application/json content-type).

curl --location --request POST 'https://{{public-api-url}}/v1/resource' \
--header 'Authorization: Bearer 34fdabeeafds=' --header 'X-Store-Id: 321'
--data '{"foo": "bar"}'

The Public API is able to send notifications to your system via HTTP POST requests.

Every webhook is signed using HMAC-SHA256 that is present in the header X-HMAC-SHA256, and you can also authenticate the requests using Basic Auth, Bearer Token or HMAC-SHA1 (legacy). Please, refer to Webhook Authentication Guide for more details.

Please work with your Account Representative to setup your Application's Webhook configurations.

Example Base-URL = https://{{your-server-url}}/webhook

Notification Schema

Notification Request Example

curl --location --request POST 'https://{{your-server-url}}/webhook' \
--header 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.142 Safari/537.36' \
--header 'Authorization: MAC <hash signature>' \
--header 'Content-Type: application/json' \
--data-raw '{
   "eventId": "123456",
   "eventTime": "2020-10-10T20:06:02:123Z",
   "eventType": "orders.new_order",
   "metadata": {
      "storeId": "755fd19a-7562-487a-b615-171a9f89d669",
      "applicationId": "e22f94b3-967c-4e26-bf39-9e364066b68b",
      "resourceHref": "https://{{public-api-url}}/v1/orders/bf9f1d81-f213-496e-a026-91b6af44996c",
      "resourceId": "bf9f1d81-f213-496e-a026-91b6af44996c",
      "payload": {}
   }
}

Expected Response

The partner application should return an HTTP 200 response code with an empty response body to acknowledge receipt of the webhook event.

Please, refer to Rate Limiting Guide for more details.

The APIs use standard HTTP status codes to indicate the success or failure of a request. Error codes are divided into two categories: 4XX codes for client-side errors and 5xx codes for server-side errors.

4XX Client-Side Errors

Client-side errors are indicated by status codes in the 4xx range. These errors are typically the result of a problem with the request made by your application. If a client-side error occurs, our API will return a response that includes an appropriate error message. This message will provide information about the cause of the error. The aim of these messages is to assist you in identifying and resolving the issue. For example, if you submit a request with missing or invalid parameters, you might receive a 400 Bad Request error with a message indicating which parameters were missing or incorrect.

5XX Server-Side Errors

Server-side errors are represented by status codes in the 5xx range. These errors suggest a problem with our server, not with your application's request. Server-side errors are typically transient, meaning they are temporary. If a server-side error occurs, we recommend that the client retries the same request with the exact same parameters. For example, if you get a 500 Internal Server Error, it's possible that our server is suffering a temporary problem. In such cases, retrying the request after a short delay is often successful. If you continually receive server-side errors, reach out to our support team for further assistance.

Endpoints to manage store onboarding and status

Endpoints to handle token management.

Endpoints for callback management.

Endpoints to manage delivery.

Endpoints to handle financial data.

Endpoints to interact with product inventory.

Endpoints for applications managing menus related data and operations.