Skip to content
AchaduDevelopers
Operational APIGo to website
Dashboard
Achadu/Developers/Versioning

Compatible evolution, explicit migrations.

The main version is in the URL. Additive changes go into v1 without breaking clients; Incompatible changes require a new version and migration window.

What might change in v1

New endpoints

Additional operations and features may be published.

New optional fields

Clients should ignore unknown properties in responses.

New events

Subscriptions with * can have types added to the catalog.

New values

Open enums can gain documented states or providers.

What requires new version

Remove or rename

Existing endpoint, field, or value does not disappear silently.

Change meaning

Incompatible semantics, unit or format requires new contract.

Make it mandatory

An optional field does not become mandatory within the same version.

Change authentication

Incompatible authorization changes receive their own migration.

Depreciation cycle

1
Announcement

Change enters history with replacement and impact.

2
Migration

The two forms coexist during the informed window.

3
Notice in production

Documentation and responses identify the discontinued contract.

4
Closing

Removal only takes place on the announced date.

How to Write a Resilient Client

Ignore unknown response fields.
Treat unknown enums as unsupported valid state.
Don't depend on the order of JSON properties.
Use the version from the URL, not a version inferred from the SDK.
Track history before updating a generated customer.