OrdstageDocs

Get started

Ordstage API

Connect your own systems to Ordstage with a REST API, signed webhooks and a test workspace.

The Ordstage API lets a business connect its own systems (a clinic system, a hotel PMS, a booking site, a CRM) to Ordstage. Your system can read and write the same data the Ordstage dashboard and assistant use, and Ordstage tells your system when something changes through signed webhooks.

The basics

Base URL https://api.ordstage.com/v1
Format JSON in and out (Content-Type: application/json), UTF-8
Authentication A workspace API key in Authorization: Bearer <key> or X-Api-Key: <key> (Authentication)
Live and test ord_live_ keys reach your real business; ord_test_ keys reach its test workspace (Sandbox)
Errors One envelope for every error, with a stable code (Errors)
Safe retries Idempotency-Key on requests that create something (Idempotency)
Limits Per key, per minute, reported in X-RateLimit-* headers (Rate limits)
Versioning /v1 in the path; only additive changes within a version (Versioning)
Times ISO 8601. Booking times are local to the calendar and carry its offset

Every answer carries a Request-Id header. Quote it when you contact support.

Who can use the API

The API is part of paid plans (Growth and up). An owner or admin creates keys in Settings → Developers in the Ordstage dashboard. A key can only do what its scopes allow, and only while the business still has the matching feature: if the bookings module is turned off, keys with booking scopes stop reaching bookings at once, and start again when it is turned back on.

What is available

Area Endpoints Scopes
Bookings Calendars, availability, bookings from every source, pushing your own bookings and closures bookings:read, bookings:write

More areas (the business profile, team members, webhooks, assistants, conversations, contacts, leads, orders and products) follow in later releases. They will be listed in the changelog.

Where to start

  1. Follow the Quickstart with a test key.
  2. Read Authentication before you put a key in production.
  3. Subscribe to webhooks instead of polling for changes.
  4. Use the API reference to try each endpoint against your test workspace.