Skip to content

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.

Bring your integration question to the demo.