Guide
Versioning
The version is in the URL. Within it, the API grows but does not break: new things appear, existing ones keep working the way they do today.
The version
The current version is v1, and it is part of every URL: https://api.closepact.com/v1/api. A version that changed how existing requests behave would get a new path, and v1 would keep answering as it does.
What can change in v1
These are additive, and can happen at any time without a new version or notice:
- New endpoints, and new resources.
- New optional request fields and query parameters.
- New fields in responses and in webhook payloads.
- New values in enums — a new deal stage, a new invoice status.
- New webhook event types.
- New error codes, for situations that could not happen before.
- Changes to the wording of
messagein errors.
Each one is listed in the changelog.
Breaking changes
These only happen in a new version, announced in advance in the changelog:
- Removing or renaming an endpoint, a field or an enum value.
- Changing a field's type or meaning.
- Making an optional field required, or adding a required one.
- Changing what an existing status code or error code means.
Something on its way out is first marked deprecated in the reference, with what to use instead, and keeps working for as long as the version it belongs to.
Building for change
An integration built this way keeps working through every additive change:
- Ignore fields you do not know. Do not reject a response, or a webhook, because it has more in it than you expected.
- Handle unknown enum values. Give every
switchon a status or stage a default branch. - Accept unknown events. Answer
2xxto webhook events you do not handle, and ignore them. - Switch on error codes, not messages.
erroris stable;messageis for people. - Do not depend on order — of fields in an object, or of items in a list you did not ask to have sorted.