Otter API
Overview
Build on Otter with a REST API secured by OAuth 2.0. Call endpoints to manage stores, menus, orders, and more — and receive webhooks when something changes in Otter.
Requests use https://partners.tryotter.com in production or
https://partners-staging.tryotter.com in staging. Code samples default to
production. The Try it explorer can target either host; production sends
live traffic. For workflows and integration guides, see Guides.
Making requests
Endpoints use resource-oriented URLs, JSON bodies, and standard HTTP status codes and verbs.
Example:
curl --request GET 'https://partners.tryotter.com/v1/resource/123' \
--header 'Authorization: Bearer <access_token>' \
--header 'X-Store-Id: 321'
| Header | Description |
|---|---|
Authorization | Bearer access token from your client credentials. See the Authentication guide. |
X-Store-Id | Store ID in your system for the store this call acts on. |
Most resource endpoints require Authorization. Other headers are listed per operation.
POST and PUT requests follow the same pattern and send a JSON body:
curl --request POST 'https://partners.tryotter.com/v1/resource' \
--header 'Authorization: Bearer <access_token>' \
--header 'X-Store-Id: 321' \
--header 'Content-Type: application/json' \
--data '{"foo": "bar"}'
Webhooks
Otter sends events to your HTTPS endpoint as HTTP POST requests.
Every webhook includes an HMAC-SHA256 signature in X-HMAC-SHA256. See the
Webhook authentication guide.
The X-Event-Id header contains the same UUID as the JSON body eventId;
use it to deduplicate deliveries and correlate callbacks.
Work with your Account Representative to configure webhook destinations for your app.
Return HTTP 200 with an empty body to acknowledge an event. See
Events and webhooks for the notification schema
and examples, or Find an event ID to correlate a
webhook with callbacks, logs, and retries.
Rate limiting and errors
See the Rate limiting guide. Per-operation limits appear on each endpoint.
Otter uses standard HTTP status codes — 4xx for client issues and 5xx for
transient server errors. Retry 5xx responses with backoff; contact support if
errors persist.
Authentication
- OAuth 2.0: OAuth2.0
The Authorization API is based on the OAuth2.0 protocol, supporting the Client Credentials and the Authorization Code flows. Resources expect a valid token sent as a Bearer token in the HTTP Authorization header.
Scopes
Scopes must be configured by our internal team to be enabled for an app. Once the scopes are configured they can be enabled on the Application Settings Page in Otter Developer Portal. Each endpoint requires a given scope that can be verified on each endpoint documentation. When generating an OAuth2.0 token multiple scopes can be requested.
Authorization Code Flow
To perform this flow, the authorization code flow must be enabled in the Application Settings Page in Otter Developer Portal. When enabling the flow it is mandatory to provide a redirect URI pointing to your application. Once the flow is complete we will redirect the user to this URI passing the 'code' and 'state' parameters. The Authorization Code flow provides a temporary code that the client application can exchange for an access token. To start the flow the application must request the user authorization. This is done by sending a request to https://partners.tryotter.com/v1/auth/oauth2/authorize. Example
curl --location 'https://partners.tryotter.com/v1/auth/oauth2/authorize?client_id=[CLIENT_ID]&redirect_uri=[REDIRECT_URI]&response_type=code&scope=organization.read&state=8A9D16B4C3E25F6A'
This call will return a 302 redirecting the user to our authorization page. If the user approves the application, we will redirect to configured URI passing the authorization code in the query parameter 'code'. The 'state' parameter is also sent to ensure the source of the data. With the authorization code, the client application can generate the token.
Client Credentials Flow
The client_credentials flow does not require any steps before generating the token. Once your application is ready, and the client_id and client_secret are available, the token can be generated by following the instructions in the next section.
Generate Token
To generate the token, use the Client ID and Client Secret (provided during onboarding), and optionally the authorization code obtained after performing the Authorization Code flow, to the Token Auth endpoint endpoint. The result of this invocation is a token that is valid for a pre-determined time or until it is manually revoked.
The access token obtained will be sent as a Bearer value of the Authorization HTTP header.
Client credentials in the request-body and HTTP Basic Auth are supported.
Request Example for client_credentials
curl --location --request POST 'https://partners.tryotter.com/v1/auth/token' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'scope=ping' \
--data-urlencode 'grant_type=client_credentials' \
--data-urlencode 'client_id=[APPLICATION_ID]' \
--data-urlencode 'client_secret=[CLIENT_SECRET]'
Request Example for authorization_code
curl --location --request POST 'https://partners.tryotter.com/v1/auth/token' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'scope=ping' \
--data-urlencode 'grant_type=authorization_code' \
--data-urlencode 'client_id=[APPLICATION_ID]' \
--data-urlencode 'client_secret=[CLIENT_SECRET]' \
--data-urlencode 'code=[code]' \
--data-urlencode 'redirect_uri=[redirect_uri]'
Response Example
{
"access_token": "oMahtBwBbnZeh4Q66mSuLFmk2V0_CLCKVt0aYcNJlcg.yditzjwCP7yp0PgR6AzQR3wQ1rTdCjkcPeAMuyfK-NU",
"expires_in": 2592000,
"scope": "ping",
"token_type": "bearer"
}
Token Usage
The token provided in field access_token is used to authenticate when consuming the API endpoints. Send the token value in the Authorization header of every request. The token expiration time is represented in the field expires_in, in seconds. Access tokens are valid for 30 days by default, but the returned expires_in value is authoritative. Store and re-use the token only while it remains valid.
Note that occasionally, a 401 error may be returned for a valid token due to an internal service issue. Such occurrences should be rare. To prevent exposing potential vulnerabilities to attackers, the Otter API does not disclose other types of errors in the authentication flow if for any reason the token can't be validated (when it's a valid token then it's ok to return 5XX or other 4XX though - such as 403). In such scenarios, although the internal auth flow avoids retries to prevent attacks, if the token is known to be valid and not expired, a retry with a backoff interval by the client is advised. Another option is to request a new token.
Example
curl --location --request GET 'https://partners.tryotter.com/v1/ping' \
--header 'Authorization: Bearer <access_token>' \
--header 'X-Store-Id: <storeId>'
Security Scheme Type: | oauth2 |
|---|---|
OAuth Flow (clientCredentials): | Token URL: /v1/auth/token Scopes:
|
OAuth Flow (authorizationCode): | Token URL: /v1/auth/token Authorization URL: /v1/auth/oauth2/authorize Scopes:
|
License
Proprietary