canonical: https://jentic.com/apis/bbot.menu/bbot # Bbot Menu Bbot API Jentic publishes the only available OpenAPI specification for Bbot API, keeping it validated and agent-ready. Bbot is a restaurant ordering and delivery platform that lets venues offer guest-led ordering, mobile checkout, and delivery from a single backend. The API covers restaurant configuration, menu publishing, table-aware fulfilment, guest profiles, Stripe-backed payment methods, price checking, and checkout. It is the integration surface for POS systems, kiosk apps, and ordering frontends that sit on top of Bbot's infrastructure. ## For AI agents Manage Bbot restaurants, menus, orders, guest profiles, and Stripe-backed payments. Useful for hospitality agents automating menu syncs, order fetches, or checkout flows. ## Scope Does not handle accounting, payroll, or non-restaurant retail commerce - use for restaurant ordering, menu publishing, and guest checkout via Bbot only. ## Capabilities - Authenticate operators against Bbot via POST /authenticate to obtain a bearer token - List restaurants and read or update per-restaurant settings - Publish menus asynchronously with POST `/menus/async-upsert` and poll for completion - Fetch tables and the fulfillable menu items for a specific guest table - Run a price check, save a Stripe payment method, and complete checkout in a single guest flow - Look up guests, create new guest records, and check whether a restaurant can deliver to a given address ## Use cases ### Menu Sync from POS to Bbot When a restaurant updates prices or stock in its POS, the change must propagate to Bbot's ordering surfaces. POST `/menus/async-upsert` accepts the full menu payload and returns an idempotency_id, which the client polls via GET `/menus/async-upsert/{idempotency_id}` until publishing completes. Suitable for nightly menu syncs or mid-service price updates. Example prompt: Call POST `/menus/async-upsert` with the new menu, then poll GET `/menus/async-upsert/{idempotency_id}` every 5 seconds until status is complete ### Table-Aware Guest Ordering Guests scan a table QR code and the ordering app needs to load the menu items fulfillable from that table. GET `/fulfillable-menu-items/{table_short_id}` returns the relevant menu, then the guest builds an order, runs POST /pricecheck, and completes via POST /checkout. The flow is purpose-built for in-venue ordering. Example prompt: Call GET `/fulfillable-menu-items/{table_short_id}` to load the menu, POST /pricecheck for the cart, then POST /checkout to place the order ### Delivery Eligibility Check Before showing a delivery option to a guest, the app should confirm the restaurant can serve that address. GET `/can-deliver/{restaurant_id}` (with the address in query parameters) returns a boolean and any constraints, so the client can switch between pickup-only and delivery flows without a failed checkout. Example prompt: Call GET `/can-deliver/{restaurant_id}` with the guest's address and toggle the delivery option in the UI based on the response ### Stripe Payment Method Capture Guests checking out via Bbot save a card through Stripe. The flow uses GET /create-stripe-setup-intent to start the SetupIntent, the client confirms the card with Stripe.js, and POST /save-stripe-payment-method stores the resulting payment method. Subsequent orders for the same guest can reuse the saved method via GET `/get-payment-methods/{guest_id}.` Example prompt: Call GET /create-stripe-setup-intent, confirm with Stripe.js client-side, then POST /save-stripe-payment-method with the resulting payment method ID ### Agent-Driven Order Lookup via Jentic A restaurant ops agent can use Bbot through Jentic to answer questions like 'how many orders are open for restaurant X right now?' without hand-rolling auth and pagination. Jentic isolates the bearer token and exposes the 19 Bbot operations as discoverable tools indexed by natural-language intent. Example prompt: Search Jentic for 'list bbot orders', load the GET /orders schema, and execute with the restaurant filter to return the current open orders ## Key endpoints | Method | Path | Description | | --- | --- | --- | | POST | `/authenticate` | Authenticate and receive a bearer token | | GET | `/restaurants` | List restaurants the operator has access to | | POST | `/menus/async-upsert` | Publish a menu asynchronously | | GET | `/orders` | List orders for the current restaurant | | GET | `/fulfillable-menu-items/{table_short_id}` | Get menu items fulfillable from a table | | GET | `/can-deliver/{restaurant_id}` | Check whether the restaurant can deliver to an address | | POST | `/pricecheck` | Run a price check on a cart | | POST | `/checkout` | Complete checkout for an order | ## Key resources - **Authentication** — Issue bearer tokens via POST /authenticate - **Restaurants and Settings** — List restaurants and read or update per-restaurant settings - **Menus** — Async menu upsert (publish) and idempotency-based status polling - **Tables and Fulfillment** — Fetch tables for a restaurant and the menu items fulfillable from each table - **Orders** — List orders for the current restaurant or fetch a specific order - **Guests** — Create and list guest profiles tied to orders and payment methods - **Payments** — Stripe setup intents, payment method save/list, price-check, and checkout ## Why Jentic - **Setup:** Wiring the Bbot API by hand means running the POST /authenticate exchange for a bearer token, learning the menu, order, and checkout endpoints, and threading restaurant and table ids through the fulfilment calls yourself. Through Jentic you install once, import the Bbot API from the API Directory, store the operator credentials once, and your agent calls it. - **Permission scoping:** Bbot puts the restaurant id in the URL path (`/can-deliver/{restaurant_id}` and `/fulfillable-menu-items/{table_short_id}`), so a rule can pin your agent to one restaurant: it reads that restaurant's menu items and delivery status and nothing else. You choose the operations it may call, so menu upserts or checkout are not included unless you add them. - **Credential handling:** Your Bbot operator credentials and the resulting bearer token are stored once, encrypted, by your own Jentic One instance and injected at execution time. They never enter the agent's prompt, logs, or context. - **Discovery method:** Agents search Jentic by intent such as 'publish a Bbot menu' or 'list Bbot orders', and Jentic returns the matching Bbot operation with its input schema so the agent calls the right endpoint without browsing the reference docs. ## Related APIs - **Basesnap API** — Database snapshot service - useful for backing up the database that mirrors Bbot menus and orders - **Baseten API** — ML model deployment - pair with Bbot to serve menu-recommendation or demand-forecasting models - **BBC Nitro API** — Unrelated domain; included as placeholder peer since the corpus has no direct restaurant-ordering competitor ## FAQ ### Why is there no official OpenAPI spec for Bbot API? Bbot does not publish an OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call Bbot API via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer. ### What authentication does the Bbot API use? Bbot uses a bearer token. Call POST /authenticate with operator credentials to receive a token, then pass it as Authorization: Bearer on subsequent calls. Through Jentic, operator credentials live in the vault and the agent only receives a scoped token. ### Can I publish a menu to Bbot programmatically? Yes. POST `/menus/async-upsert` accepts the full menu payload and returns an idempotency_id. Poll GET `/menus/async-upsert/{idempotency_id}` until the publish completes - this lets you treat menu publication as an asynchronous job rather than a long-running call. ### How do I check if a Bbot restaurant can deliver to an address through Jentic? Search Jentic for 'check bbot delivery eligibility', which surfaces GET `/can-deliver/{restaurant_id}.` Load the schema, supply the restaurant ID and address, and execute to receive a delivery decision before showing the option to the guest. ### What are the rate limits for the Bbot API? The OpenAPI spec does not declare explicit rate limits. Treat menu upsert as a heavyweight operation and avoid concurrent POST `/menus/async-upsert` calls for the same restaurant. Check the Bbot operator dashboard for any per-account quotas. ### Does the Bbot API support Stripe payments? Yes. GET /create-stripe-setup-intent starts a SetupIntent for card capture, POST /save-stripe-payment-method stores the resulting payment method, and GET `/get-payment-methods/{guest_id}` lists saved methods for repeat orders. Checkout itself is completed via POST /checkout. ### Can I limit what my agent is allowed to do with the Bbot API? Yes. Because you run Jentic One yourself, your own rules decide which Bbot operations and credentials the agent may use. Since Bbot carries the restaurant id in the URL path on calls like GET `/can-deliver/{restaurant_id}` and GET `/fulfillable-menu-items/{table_short_id}`, a rule can pin the agent to a single restaurant so it only reads that venue's menu items and delivery status. You also choose the operations it can call, so write actions such as POST `/menus/async-upsert` or POST /checkout stay off unless you explicitly add them.