API Reference
API-wide contracts and exact generated VRPlatform operations
Use this section for exact generated request and response schemas plus the small set of contracts that apply across operations.
API-wide Contracts
- Authentication summary
- Asynchronous operations
- Error contract
- Pagination and filtering
- Dry Run Mode
- Books Closed Override
- Issue Catalog
- Webhook Catalog
- Changelog
Generated Operations
Endpoint pages are generated from the public OpenAPI document and grouped by resource in the sidebar. They are the exact contract for paths, methods, fields, query parameters, schemas, and operation-specific dry-run support.
For client generation, browse the interactive reference at
https://api.vrplatform.app/spec and fetch the OpenAPI document from
https://api.vrplatform.app/openapi.json.
Common entry points:
For business decisions and complete workflows, start at Build your own UI, Integrate data, or Operate.
Versioning and deprecation
The API has one live version. We change it in place and do not publish v1, v2 or date-pinned versions. Compatible changes ship without notice. Breaking changes follow the notice period below.
What is not breaking
We may do these at any time:
- Add an endpoint, an optional request field, or an optional query parameter.
- Add a response field, an enum value in a response, a webhook event type, or an audit event type.
- Add a new issue code or error
contextkey. - Change the order of keys, the length of generated IDs' text, or undocumented behavior.
- Relax a validation rule.
- Fix behavior that contradicts the documentation or the OpenAPI schema.
- Change rate limits or page-size defaults within documented bounds.
Write clients to ignore unknown fields. Treat response enums as open and handle an unknown value as "unsupported".
What is breaking
- Remove or rename an endpoint, a field, a query parameter, an enum value you send, or a webhook event type.
- Change a field's type, format, nullability, or meaning.
- Make an optional request field required, or make validation stricter for input that was valid.
- Change the status code, error
message, or issue code that a documented condition returns. - Change the default of a request field or query parameter.
- Change a documented sort order, or a lock or permission rule, so that a documented valid call fails.
- Change webhook signing, the delivery envelope, or authentication.
Notice
| Change | Notice before it takes effect |
|---|---|
| Breaking change to a generally available endpoint or field | At least 90 days |
| Breaking change to a feature marked "Work in progress" in the guides | At least 14 days |
| Security, legal, or data-integrity fix that cannot wait | As much as we can give, at least announced the same day |
Notice starts on the day the deprecation is published in the changelog and sent to partners. The removal date is fixed in that notice. We do not move it earlier. We may move it later.
Scheduled breaking changes ship on the first day of a month. The initial compatibility deprecations below use the explicitly announced removal date.
Deprecation process
- Announce. Add a
Deprecated:entry to the changelog with the removal date, the replacement, and a migration step. Send the partner notice (below). - Mark. Set
deprecated: truein the OpenAPI document for the operation or field, with the replacement in its description. Mark the operation in the generated reference. - Signal at runtime. Every response from a deprecated operation carries these headers:
Deprecation: @1791158400
Sunset: Sun, 03 Jan 2027 00:00:00 GMT
Link: <https://docs.vrplatform.app/api/changelog#2026-10-05>; rel="deprecation"Deprecation is the date notice began, as a Unix timestamp in the format of RFC 9745. Sunset is the removal date (RFC 8594). Both headers stay until removal. A deprecated field or query parameter has no header of its own. It is named in the changelog entry and marked in the OpenAPI document.
4. Remind. We repeat the notice to partners 30 days and 7 days before the removal date.
5. Remove. On the removal date we remove the operation or field and publish a Breaking: entry in the changelog. We do not remove anything that partners still call at volume without first contacting them.
How partners are told
- The changelog is the source of record. Every deprecation and every breaking change appears there with a date.
- Partners with an integration contract (for example Hostaway) get an email to their registered technical contact, and a post in their shared Slack channel, on the notice date and at each reminder.
- The partner changelog feed complements direct deprecation notices. It does not replace them.
Webhooks and audit events
Webhook payloads and audit events follow the same rules. Their documented version and any payload contract version identify the contract a receiver gets. Breaking changes require a new contract version. A new field or event type is not breaking.
