Quickstart
Get credentials, connect a store, call the Otter API, and receive a verified webhook — in one path.
By the end of this guide you will have application credentials, at least one linked store, a successful authenticated API call, and a webhook endpoint that validates Otter signatures.
Before you begin
- A technical contact who can store secrets securely
- A publicly reachable HTTPS URL for webhooks (or a tunnel such as ngrok for local testing)
- Agreement with your Account Representative on which products you are building (orders, menus, storefront, and so on)
Step 1: Register your application
External partners need a registered application before calling the Otter API. Registration is manual.
- Contact your Account Representative and ask them to register your application.
- You receive:
- Application ID (also called Partner ID in older materials — treat them as the same)
- Client secret
- Store the client secret in your secrets manager. Never commit it to source control or expose it in a browser or mobile app.
Verify
You have Application ID and client secret stored securely. See the API reference for authentication and base URLs.
Step 2: Authenticate and make your first call
The Otter API uses OAuth 2.0 access tokens. Most partner apps start with the client credentials flow. See Authentication for flows, headers, scopes, and webhook verification.
- Obtain an access token from
POST /v1/auth/tokenusing your Client ID and client secret (details in the API reference). - Call a simple authenticated endpoint with:
Authorization: Bearer <access_token>
- Confirm you get a successful response before wiring a full workflow.
Verify
A successful authenticated response with your credentials means the application is wired correctly.
Step 3: Connect your stores
Every restaurant location your app acts on must be paired with Otter. Store-scoped requests send the Otter store identity in X-Store-Id. Pairing paths (Account Representative, account pairing APIs, organization OAuth): Stores and connections.
- Ask your Account Representative to onboard each store, or automate pairing with Stores & account pairing / Organization onboarding when your product supports it.
- After linking, note the store ID Otter expects for that location.
- Send it on store-scoped requests:
Authorization: Bearer <access_token>
X-Store-Id: <store_id>
Verify
Call a store-scoped endpoint from the API reference with X-Store-Id set. You should not get an unknown-store or authorization error for that header.
Step 4: Register webhooks and verify signatures
Otter pushes events (order status, menu failures, storefront changes, and more) to HTTPS endpoints you control. Mental model (REST vs webhooks, ack, error callbacks): Events and webhooks.
- Ask your Account Representative to register your webhook URL(s) and choose an authentication type per endpoint.
- Save the webhook secret for each endpoint (Otter Developer Portal or your Account Representative).
- Implement your receiver to:
- Accept
POSTwith JSON - Validate
X-HMAC-SHA256on every request — see Keep webhooks secure - Return 2xx quickly; do heavy work asynchronously
- Subscribe to the event types your product needs.
Verify
Trigger a test event (or complete a small flow that emits one). Your endpoint should receive the request, pass signature validation, and respond with 2xx.
Checklist
You're done when:
- Application ID + client secret stored securely
- Authenticated API call succeeds
- At least one store linked;
X-Store-Idaccepted - Webhook URL registered; signature validation passes
Common failures
| Symptom | Likely cause | Fix |
|---|---|---|
| 401 on API calls | Wrong secret or expired token | Confirm credentials; refresh the bearer token |
| Store errors on resource calls | Missing/wrong X-Store-Id or store not linked to this app | Re-check store onboarding; use the Otter-linked id |
| No webhooks | URL not registered, HTTP (not HTTPS), or firewall | Confirm Otter can reach the URL |
| Signature check fails | Wrong secret or hashing decoded/parsed body | Use the raw request body bytes — see Keep webhooks secure |
| Frequent 429 | Hitting rate limits | Back off with jitter; contact your TAM if normal traffic is limited |
Next
- Otter 101 — Core business concepts (organization, store, orders, menus, events)
- Authentication — Tokens outbound; webhook verification inbound
- Events and webhooks / Stores and connections — Shared primitives
- Pick an Integrations hub from the Overview and follow its Integration overview
- Keep webhooks secure and Understand rate limits before live traffic