Developers
The same 231 routes the app uses.
liverybook exposes a REST API under /api/v1 with an OpenAPI schema, API-key authentication with scopes, outbound webhooks, and per-tenant isolation on every call. The reference documentation is generated from the code and lives with the API itself.
What an integrator gets.
One API, the app's own
The operator app, the portal and your integration call the same endpoints under /api/v1. There is no second, smaller partner API.
OpenAPI 3 schema
Generated from the code with drf-spectacular. Swagger UI at /api/docs/ and ReDoc at /api/redoc/, both against the live schema.
API keys with scopes
Keys are created per tenant, hashed with bcrypt, and carry scopes such as bookings:write. Send them as a Bearer token.
Webhooks with retries
Register an endpoint and receive events on tracked resource changes. Failed deliveries retry with exponential backoff every two minutes.
Envelope responses
Every response is { data, meta, errors }. Errors carry a code, a field and a message; invalid status transitions are a code, not a 500.
Status machines apply to you too
The API enforces the same 25 booking and leg transitions as the run board. A client cannot move a leg from unassigned to completed.
curl https://api.liverybook.com/api/v1/bookings/ \
-H "Authorization: Bearer <api-key>"
{ "data": [ ... ], "meta": { "page": 1, "total": 247, "per_page": 25 }, "errors": null }API access is included on Professional and Enterprise. Keys are issued from the operator app by a tenant admin.