Customer account signup/login and other CRUD operations.
Bite API (v2)
Overview
Bite exposes online ordering functionality through a REST API which third party developers can use to create applications on top of the Bite platform.
A Bite "Customer" represents a full end-user account created on Bite's platform. Customers can be created with a Bite password or can be authenticated against a Single Sign-On provider such as Paytronix or Punchh. Bite Customers have the following features:
- A single set of credentials could be used to create completely different accounts under different brands that Bite works with.
- Storing credit cards on file so that they could be used for future purchases.
- Access to the customer's favorite ordered items and recent order history.
- Storing delivery addresses on file for future purchases.
After creating or authenticating a Bite Customer through the API, a unique authentication token will be returned which can be used to refer to that user from that moment on without the need to store their password in your application.
A dedicated sandbox environment will be provisioned for each new third-party developer. All development and testing must be carried out through that environment. It will include both an API sandbox as well as Admin Portal sandbox so that test locations could be modified by the developers for the purposes of testing their integration with Bite. The Sandbox environment runs the same code as production. https://YOUR_SANDBOX_SUB_DOMAIN.getbite.com/api
The production environment endpoint is: [REDACTED]
All communication must be encrypted over TLS 1.2
https://<environment_domain>/<API_version>/<resource>?[params]
- Bite API expects both the request and the response bodies to encoded with JSON, so both the HTTP Accept and Content-Type headers should be set to application/json.
- HTTP Status Codes will be returned as follows:
- 200 OK - The requested operation completed successfully!
- 400 Bad Request - An error occurred on the Bite side or on the POS side. Please reference the response body's "code" value in the Bite Error Codes documentation.
- 403 Forbidden - Invalid API credentials or insufficient access to a resource or operation.
- 500 Server Error - An unexpected error occurred. Please verify that your request is correctly formatted.
- Every API call must include the following headers:Header
Description Example x-md-api-version Must be set to 4 x-md-api-version: 4 x-bite-org-id Must be set to the brand id that you are working with. This value will be provided along with the sandbox environment. x-bite-org-id: 5fa31dc97acd2f0031e023eb x-customer-app-scope Must be set to the brand's account scope. This value will be provided along with the sandbox environment. x-customer-app-scope: my-brand-scope Authorization Must be set to Bearer: API_TOKEN. The API_TOKEN will be provided along with the sandbox environment. Authorization: Bearer 2979c798-c901-4ceb-8478-3b26c24a998d User-Agent Unique user agent value that identifies the app. Please send this formatted as application_name/version. User-Agent: SomeApp/v1.2.3 X-Device-Id Unique hardware identifier for the device. X-Device-Id: 993e0082-5bfd-4bbc-98ec-d13b50bbd54a
A success response structure will look as follows:
{
success: true;
data?: {...};
}An error response structure will look as follows:
{
success: false;
code: number;
message?: string;
data?: {...};
}Any error response will contain an error code:
| Code | Meaning | Suggested Action |
|---|---|---|
| 60 | Customer Password Already Used: The customer is trying to use a password they have previously used. | |
| 61 | Customer Token Invalid: The token has been malformed or has expired. | Maybe the customer needs to log out and log in again because they've changed their password. |
| 62 | Customer Account Not Verified: The customer resource being accessed requires a verified customer account. | |
| 63 | Customer Account Disabled: The specified customer account has been disabled by one of the brand admins. | |
| 64 | Customer Account Deleted: The specified customer account has been deleted by one of the brand admins. |
Please treat all IDs in the API as strings.
We will not remove properties from the current API version, but we do add new properties to return objects from time to time.
There is no guaranteed ordering of properties. We request that properties are accessed by name and not by index.
Please do not rely on error messages for logic. Error text may change periodically. Rather rely on error codes, which are guaranteed to not change.
Some API endpoints are protected through the use of rate limiting. The base rate limit can be found in the description of the API endpoint.
Information about the current usage can be found in the headers of the response:
- Ratelimit-Limit: The amount of requests permitted
- Ratelimit-Remaining: How many requests can be made in the interval
- Ratelimit-Reset: How long, in seconds, until the rate-limit interval ends and the remaining amount of requests resets
The rate limit maximum is adjusted by the number of locations associated with the token. For example, if an API has a base rate limit of 50 requests per minute, then an organization with 10 locations may use the API endpoint 500 times per minute.
2026-02-24
- Updated definitions of openingHoursByFulfillmentMethod
2025-07-23
- Updated security for Bite API Token based requests
2024-08-29
- Added
consentedToMarketingfield to order
2024-01-22
- Added section to ordered item schema
2024-01-03
- More details regarding rate limiting
2023-11-07
- Deprecated:
POST /api/v2/reporting/orders/day - New Endpoint:
GET /api/v2/reporting/orders/day/:date
2022-12-19
- Updated rate limits of API calls
- Reversed order of change log
2022-10-25
- New endpoints:
- POST /api/v2/reporting/orders/day
- GET /api/v2/locations
- Rate Limiting
2021-10-19
- First Draft
Download OpenAPI description
Languages
Servers
Mock server
https://documentation.getbite.com/_mock/openapi/v2/bite-api-v2
Sandbox
https://{sandboxApiSubDomain}.getbite.com/api
It's possible for customers to embed the Bite ordering experience in their own proprietary mobile app. The intended use-case is to offer a seamless food ordering experience as part of a bigger application that does not require the user to leave the mobile app to go to a browser on their phone.
One critical integration that makes this feature attractive is the ability to preload a Bite website with the user information that is already available to the mobile app. This can be some information about the user such as their name or loyalty card number. Alternatively, this could be a set of methods of payment. Bite will make use of that information and the ordering experience will appear as if the guest has logged in on Bite.
version must be always set to 2
loyaltyAuthValues are used to authenticate the guest into the loyalty program
cards are used to pass in any possible saved payment methods
validAt is a unix timestamp (in ms) that represents the time at which the token was generated by the mobile app
{
version: 2,
loyaltyAuthValues: {
method: 'auth-token' | 'card-number';
value: string;
}[];
cards: {
cardNumber: string;
cardName: string;
}[];
validAt: number
}The session token is an encrypted representation of the session info that can be safely passed in a query string parameter of a Bite web ordering url. Generation steps:
- Construct the SessionInfo object as described above.
- Set
validAtto be the current time (as a unix timestamp in milliseconds). For security purposes, thesessionTokenmust include the timestamp at which it was generated so Bite could verify that it was generated within 15 seconds of receiving the request. The purpose of this measure is to avoid replay attacks. - Stringify it.
- Encrypt the resulting string with the secret key using the
AES-256-ECBalgorithm. - Encode the resulting string with base64.