Skip to main content
Menu data is valuable. It represents a restaurant’s brand, pricing strategy, and competitive positioning. It also powers limited-time offers, regional variations, and location-specific pricing. EveryBite’s access levels give restaurants complete control over who can access their data, what information they can see, and who can update it. A chain with different menus in the South? Supported. A franchisee who manages their own LTOs? No problem. A parent company that needs visibility across all brands? Built in.

​
Why Access Levels Matter

Restaurant ownership structures are complex. A single restaurant, a regional franchise group, and a global brand parent company all have different needs—and different rights to the data. Consider a parent company like Yum! Brands. They own Taco Bell, KFC, and Pizza Hut. A technology partner building an app for Yum! needs access to all three chains. But a franchisee building a local ordering app should only see their own locations. And a third-party delivery service partnering with one KFC location shouldn’t see data from the location across town. EveryBite’s access levels mirror these real-world relationships: This structure ensures:
  • Chains maintain consistency while allowing regional variation
  • Parent companies get portfolio-wide visibility without exposing individual operator data
  • Third-party partners access only what they’ve been explicitly granted

​
API Keys

Your API key is your credential for accessing menu data. Each key is scoped to a specific level in the restaurant hierarchy based on your relationship with the brand. Authentication is done by setting the Authorization header to the raw API key value. The value starts with pk_. Do not add a Bearer prefix.
If you are testing requests in the docs explorer or directly against https://api.everybite.com/graphql, set:
  • Header name: Authorization
  • Header value: pk_YOUR_API_KEY
Paste only the raw pk_... value into the auth or headers tab.
Postman users: Do not use the Authorization tab with type “Bearer Token” — Postman will prepend Bearer to the value, which will cause authentication to fail.Instead, go to the Headers tab and add the key manually:If your chain API key is restricted to specific origins, also add an Origin header with one of the approved values, otherwise the request will be rejected:

​
Key Types

For: Single-location restaurants or franchiseesAccess: One restaurant location and its menus

​
Getting Your Key

Coming Soon — We’re rolling out developer sandbox access. Contact us to join the early access waitlist.
Once approved, you’ll receive API credentials through our partner onboarding process. Your key identifies which restaurant brand’s menu data your application can access.
Keep your API key secure. Do not expose it in client-side code or public repositories. Always proxy API requests through your backend.

​
Environments

Sandbox access is rolling out to early partners. Contact us to join the waitlist.

​
Session-Based Context

All guest context is bound to the session when you call startSession. This includes:
  • Chain & Location — Which restaurant and location
  • Platform — Touchpoint: IOS, ANDROID, WEB, KIOSK, POS, VOICE
  • Guest Identity — Your guest ID or loyalty ID
  • Passport — EveryBite Passport ID, if they have one
Once the session is created, your runtime API calls only need three headers:

​
EveryBite Passport

If a guest has an EveryBite Passport, include their passportId when starting the session. This loads their saved dietary preferences automatically—no need to pass filters manually. See the Quickstart for complete session and header examples.

​
Rate Limits

Rate limit headers are included in every response:

​
Error Codes