Getting started

1. Get a key

An operator creates an API key in the back-office developer settings. The plaintext is shown once at creation; only a SHA-256 hash is stored. Use a sb_test_… key while building. See Authentication for the other credential types (OAuth2 client-credentials, auth-code + PKCE for marketplace apps, and static tokens) and the full scopes table.

2. Make a call

Authenticate with a Bearer credential:

curl https://api.storebay.co.uk/v1/sites \
  -H "Authorization: Bearer sb_test_…"

{
  "data": [
    {
      "id": "018f9c2a-7b3e-7c1a-9f2d-3a5b6c7d8e9f",
      "object": "site",
      "name": "StoreBay Croydon",
      "timezone": "Europe/London",
      "status": "active"
    }
  ],
  "meta": { "limit": 25, "cursor": { "next": null, "has_more": false } }
}

Every response uses the { data, meta } envelope — see Conventions.

3. Subscribe to webhooks

Register an endpoint and StoreBay will POST signed, versioned events (agreement.signed, invoice.paid, payment.succeeded, …) as they happen — far better than polling. See Webhooks.

Environments

Sandbox is included, has identical RLS isolation, and there is no parallel schema — the switch is the credential, and the base URL does not change. Build against sb_test_…, then swap to sb_live_… to go live. Nothing else in your integration changes. See Sandbox for the full model, including what going live actually does to your test keys.

Ready to build something real?

Follow Build a booking flow end to end — the full availability → contact → reservation → order → agreement → payment → subscription chain, worked end to end against this same sandbox.