Versioning
For simplicity, most data is unversioned. When versioning is necessary, it is done using dates.
When you specify a version, the data you receive will be the newest version that is not newer than the version specified. Unless the specified version is older than the oldest version of the data. In that case, you receive the oldest version of the data. If the version specified matches the data version exactly, then that version of the data will be sent.
Examples
Suppose we have an interface with the following versions:
- unversioned
- 2022-02-02
- 2022-04-04
The version actually used for the one specifed will be:
| Specifed | Used |
|---|---|
| 2022-01-01 | unversioned |
| 2022-02-02 | 2022-02-02 |
| 2022-03-03 | 2022-02-02 |
| 2022-04-04 | 2022-04-04 |
| 2022-05-05 | 2022-04-04 |
API Versions
The specified version of an API endpoint can be defined using the Meld-Version header or relying on the default version defined on the account. The initial default version is set to the date the API key is created on the account. This effectivly locks you in to the current state of the APIs. If new versions of an endpoint are ever added later, you will need to explicitly migrate to that version by either updating your default version for all endpoints or specfiying the version for that endpoint directly with the header.
All API responses include a Meld-Version header, which contains the actual version of the endpoint used.
Webhook Versions
The specified version of a webhook event is defined in the webhook profile All webhook events sent to the URL in that profile will use this specified version.
All webhook events include a version attribute in its payload to indicate which version of the event was actually used.
Updated 2 months ago