Our philosophy is to try and avoid creating new versions as much as possible. Any changes to an APIs payload, either in creation or in responses, should be as backwards compatible as possible. We do not consider adding new endpoints to be โbreaking changesโ, so would not consider releasing a new version. Complete backward compatibility over the long term is unrealistic. Every serious API must offer a mechanism to deal with breaking changes. Our approach is to version API endpoints by service and in the request URLโs path. This implies that if we only need to make changes to a single service, all the other services are isolated. Itโs easier to log or debug requests and extract statistics from logging data. Youโll see in the documentation that each serviceโs end-points include the version in the URL path, a few examples:Documentation Index
Fetch the complete documentation index at: https://invopop-fr-lookup.mintlify.app/llms.txt
Use this file to discover all available pages before exploring further.
-
GET https://api.invopop.com/utils/v1/ping -
PUT https://api.invopop.com/transform/v1/jobs/XXXXXX -
GET https://api.invopop.com/silo/v1/envelopes
transform/v1 to transform/v2 as part of their migration process.