API overview

Understand what is already documented for the OmniLab API and where to start before the full reference is published.

1 min read

Your backend calls the API and receives webhooks, while functions run your own code on the platform.

What the developer surface is used for

  • Server-to-server authentication with client credentials
  • Booking self-service experiences, such as listing or cancelling a participant's bookings
  • Event-driven integrations through webhooks
  • Your own TypeScript, run by the platform after an event or inside a contact sign-up, with functions
  • Integrations your Customer Success Manager enables for your account
Client credentials Bearer token Hook point Allow-listed hosts Your backend OmniLab token endpoint Approved OmniLab API endpoints OmniLab events Webhook subscriptions Your webhook receiver Your functions, run by OmniLab Contact sign-up in OmniLab Your systems or providers Your website or app Embedded OmniLab experience

What is not published yet

The full resource-by-resource REST reference is not published in this help centre yet. Do not assume that an endpoint you discover elsewhere is part of the supported external surface.

Treat the API as an approved surface, not a discovery exercise

Use only the endpoints and flows confirmed for your account. If you need broader API coverage, agree it with your Customer Success Manager before development starts.

  1. Read Authentication.
  2. Record your staging and production API hosts before you write code.
  3. Build the first use case against staging.
  4. Prefer webhooks over aggressive polling when another system needs timely updates.
  5. Use a function when the code should run on the platform, not your server.
  6. Keep unsupported or not-yet-published areas behind a feature flag on your side.

Next steps

On this page

What the developer surface is used forWhat is not published yetRecommended starting pathNext steps