Versioning
The merchant API and its documents are version 1, and inside v1 they only grow. An integration written against v1 keeps working.
Paths, field names, error codes, header names and code samples stay in English: they are the contract.
What may change inside v1
- A new optional field in a response, a request or the order document.
- A new route, a new error code, a new webhook event or a new value in a list of allowed values.
- A new signature scheme next to
v1=inCutOptim-Signature; receivers ignore schemes they do not know.
What never changes inside v1
- No field disappears, is renamed or changes meaning.
- No route changes its path, its key or the shape of its answer.
- An error code keeps its meaning.
Write a tolerant reader
Ignore fields you do not know, treat an unknown error code by its HTTP status, and accept a webhook event type you have not subscribed to with a 2xx. The schemaVersion of the order document and of every webhook body is 1.
A breaking change
A breaking change would be a new document (order.v2) or a new path (/cfg/v2) next to v1, never a rewrite of v1. It would be announced in the Changelog.
There is no "try it" button here on purpose: the secret key belongs on your server, never in a browser. The demo shop shows the embed and the order hand-off working end to end.
LegalConfigurator terms ·Data processing agreement ·Shopper privacy notice ·Third-party licences