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.