Versioning
Pin a date-based API version and verify a migration to another contract
The Basker Partners API uses date-based path versioning. Every endpoint URL includes the version as a path segment, immediately after /partners/:
https://api.basker.app/partners/{version}/{tenant}/...For example, 2026-02 is the version segment in:
https://api.basker.app/partners/2026-02/remarkable-theatre/eventsSupported versions
The current runtime accepts:
| Version | Query shape |
|---|---|
2026-02 | Current version. Applies each resource's documented default field selection and relationship population when you do not supply select or populate. |
2025-07 | Legacy version. Does not apply the current default query shapes. |
GET /partners/openapi returns the current 2026-02 contract. Use GET /partners/{version}/openapi to request the contract for a specific supported version. An unsupported version returns 400 and lists the versions accepted by the running service.
Pin the version in configuration rather than assembling it dynamically. Confirm the new version's OpenAPI contract and response shapes before changing that value.
How to pick a version
- New integrations: use the most recent stable version. The default value in the OpenAPI spec is also the most recent.
- Existing integrations: stay on the version you have tested until you have compared and verified a newer contract.
Migration workflow
- Compare the versioned OpenAPI documents.
- Run representative reads and writes against the new path in a non-production workflow.
- Check field selection, populated relationships, validation errors, and any configured-field mutations you use.
- Update your integration and switch the configured path version after verification.
Related
- Authentication: auth headers don't change between versions.
- Multi-tenancy: the tenant slug appears after the version in every path.
- Errors: error shapes and status-specific details.