Introduction

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.

Bite Nomenclature

Customers

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.

Usage Basics

Environments

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

Request/Response Basics

Headers and Status Codes

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

Response Structure

A success response structure will look as follows:

An error response structure will look as follows:

Bite Error Codes

Any error response will contain an error code:

Versioning and Compatibility

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.

Rate Limiting

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.

Changelog

2026-02-24

• Updated definitions of openingHoursByFulfillmentMethod

2025-07-23

• Updated security for Bite API Token based requests

2024-08-29

• Added consentedToMarketing field 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