Versioning strategy
Understand how versioning appears in OmniLab endpoints and event types, and how to prepare for future change.
OmniLab currently exposes version markers directly in endpoint paths and event names, such as /v1/oauth:token, /v1/interactions:fetchContactBookings, and webhook event types ending in .v1.
What is versioned today
- REST endpoints under
/v1/... - Webhook event types such as
reward.won.v1andbooking.created.v1 - The payload schemas associated with those versions
Practical compatibility rules
- Treat new optional fields as additive rather than breaking.
- Treat path changes, required-field changes, or event type renames as breaking.
- Pin your receiver logic to the exact event names you subscribe to today.
- Keep contract tests in staging for token requests, booking flows, and webhook signatures.
- Validate downstream parsing before you promote a change to production.
Version markers are your first compatibility signal
While the public API reference is still expanding, the clearest signal is the version in the path or event name. Build your own tests and monitoring around those explicit contract points.
How to prepare for future change
- Keep your OmniLab integration logic behind a small adapter layer.
- Store sample request and response payloads from staging.
- Verify booking flows and webhook signature verification whenever a change is announced.
- Roll changes through staging before you promote them to production.