Versioning strategy

OmniLab 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

• REST endpoints under /v1/...
• Webhook event types such as reward.won.v1 and booking.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.

How to prepare for future change

1. Keep your OmniLab integration logic behind a small adapter layer.
2. Store sample request and response payloads from staging.
3. Verify booking flows and webhook signature verification whenever a change is announced.
4. Roll changes through staging before you promote them to production.

Next steps

• Changelog
• Authentication
• Webhook event reference