API overview
Understand what is already documented for the OmniLab API and where to start before the full reference is published.
This page stays intentionally lightweight while the full resource-by-resource API reference is being consolidated. Today, the most important public developer entry points are authentication, booking access, webhooks, and embedding patterns.
What the current 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
- Tenant-specific integrations prepared with OmniLab teams
What is not published yet
The full resource-by-resource REST reference is not published in this help center yet. Do not assume that every internal OmniLab endpoint is part of the supported external surface.
Treat the API as an approved surface, not a discovery exercise
Use only the endpoints and flows explicitly confirmed for your tenant. If you need broader API coverage, align with the OmniLab team before development starts.
Recommended starting path
- Read Authentication.
- Record the production and staging base URLs before you write code.
- Build the first use case against staging.
- Prefer webhooks over aggressive polling when another system needs timely updates.
- Keep unsupported or not-yet-published areas behind a feature flag on your side.
Related
Authentication
Request and reuse a machine-to-machine access token.
Base URLs and environments
Keep environment-specific URLs, credentials, and callback targets separated.
Common integration patterns
Start from the most common booking, CRM, and analytics patterns.
API Reference
See the status of the future resource-by-resource reference.