Introduction
Synerise RESTful APIs are a quick and simple way to integrate your existing or future systems to interact with Synerise or benefit from functionalities available within your Applications.
Articles in this section
API Reference & Postman Collection
You can find our API References here: API Reference
To open Synerise’s collection in Postman, click here: Run in Postman
Available endpoints (Areas)
The endpoints you can use are sorted into the following groups:
| Area | Slug | Description |
|---|---|---|
| Authorization | /auth | Used for authorization to use the APIs. |
| Clients | /clients | These methods allow you to manage Clients. |
| Clients Account | /my-account | Used by authenticated Clients to operate on their Accounts |
| Events | /events | These endpoints are used to track user activity by sending events to the Synerise Platform. Each listed method sends one type of events. |
| Transactions | /transactions | These methods allow you to view transactions. |
| Promotions | /promotions | These endpoints allow you to manage promotions. |
| Vouchers | /vouchers | Vouchers are stored in pools and assigned to Clients. You can import vouchers by using the API or other import methods. |
| AI | /ai | Used to integrate AI features |
API Versioning
Synerise is being built with CI/CD (Continuous Integration/Continuous Delivery) principles in mind and we often deploy changes multiple times a day.
So, as you can see, we do not have fixed release cycles, but instead features are brought live for you as soon as they are ready.
Such an approach allows us to deliver features, changes, and bug fixes very fast and keeping track of them is possible thanks to our live changelog.
Thus, as part of our API Contract, we want to ensure that within an API Version:
- No fields will be deleted or changed in a non-backwards compatible way.
- We bring changes that are additional, eg. new fields, new methods, new error messages/codes, or mandatory parameters becoming optional (but generally speaking, not causing compatibility issues).
Whenever we may need to bring things that are not backwards compatible, we will do that as a new API version for the given functional area, so an endpoint that was v1 is now also v2, with previous one still being operational.
Deprecation
For those endpoints that already have newer versions, we will send X-API-DEPRECATED in the response Headers, giving you time to switch to the new endpoint.