canonical: https://jentic.com/apis/grabbly.io/grabbly

# Grabbly API

Grabbly is a food delivery and restaurant marketplace API. The published v1 surface exposes two endpoints - listing available restaurants and placing a food order - making it a minimal but complete loop for an agent that browses menus and submits orders on behalf of a hungry user. Authentication uses an API key sent through the Authorization header.

## For AI agents

Browse available restaurants and place a food order on behalf of a user. Two endpoints cover discovery and order submission.

## Scope

Does not handle menus, payments, or order tracking in the published spec - use for restaurant discovery and order submission only.

## Capabilities

- List available restaurants on the Grabbly marketplace via GET /restaurants
- Place a food order against a Grabbly restaurant through POST /orders
- Submit order line items as part of the POST /orders body
- Authenticate through the Authorization header using a Grabbly-issued API key
- Bridge a conversational agent to a complete browse-and-order flow on Grabbly

## Use cases

### Conversational Food Ordering Agent

A chat assistant takes 'order me dinner' and walks through GET /restaurants to surface options, then POST /orders to submit the user's chosen items. The published surface is intentionally narrow - there is no menu, modifier, or order-tracking endpoint in the spec - so the agent must work within that scope and ask the user for explicit item details.

Example prompt: Call GET /restaurants, present the list to the user, then POST /orders with the chosen restaurant and item array.

### Restaurant Discovery for Local Apps

Local lifestyle and concierge apps query GET /restaurants to populate a 'food nearby' tab without operating their own restaurant database. Refresh on user open or on demand to keep the list current. The endpoint does not include menus or pricing, so apps that need item-level information must fetch that elsewhere.

Example prompt: Call GET /restaurants on app launch and render the response into a card list with the restaurant name and id for downstream order calls.

### Voice Assistant Reorder Flow

A voice assistant remembering 'usual order' presents the saved restaurant and items, confirms with the user, and submits POST /orders in one shot. The Grabbly spec does not include a saved-order primitive, so the assistant stores the prior order locally and re-uses the captured restaurant id and item payload to reconstruct the request.

Example prompt: Replay a stored Grabbly order by issuing POST /orders with the cached restaurant_id and items array after voice confirmation.

### Agent-Driven Ordering via Jentic

An AI assistant picks up a request like 'order pizza for tonight' and uses Jentic to discover Grabbly's two endpoints. The agent calls /restaurants for options, then /orders to submit. The Authorization API key is held in Jentic's vault, so the agent never handles the raw secret.

Example prompt: Use the Jentic SDK to search 'place a food order', load POST /orders, and execute with the chosen restaurant_id and items list.

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| GET | `/restaurants` | List available restaurants on the Grabbly marketplace |
| POST | `/orders` | Place a food order against a chosen restaurant |

## Key resources

- **Restaurants** — List of available restaurants on the Grabbly marketplace
- **Orders** — Order submission endpoint accepting restaurant id and items

## Why Jentic

- **Setup:** Wiring the Grabbly API by hand means setting its Authorization API key header and modelling the restaurant discovery and order submission calls yourself. Through Jentic you install once, import Grabbly from the API Directory, store the key once, and your agent calls it.
- **Permission scoping:** Grabbly takes the order details in the request body rather than a resource id in the path, so limit the agent to the operations it needs, such as reading restaurants or submitting an order. You choose the operations it may call, so the agent cannot reach anything you have not included.
- **Credential handling:** Your Grabbly Authorization API key is stored once, encrypted, by your own Jentic One instance and injected as the header at execution time. It never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'find nearby restaurants' or 'place a food order', and Jentic returns the matching Grabbly operation with its body schema so the agent does not have to model the order shape from scratch.

## Related APIs

- **Toast POS API** — Restaurant POS platform pairing with marketplaces for kitchen-side fulfilment
- **Shopify Admin API** — Hosted commerce platform for restaurants selling beyond delivery marketplaces
- **Square API** — Payments and POS that complement marketplace order capture

## FAQ

### What authentication does the Grabbly API use?

Grabbly uses an API key sent in the Authorization header (security scheme name 'apiKey'). Generate the key in your Grabbly account and send it on every request. Through Jentic, the key is stored in your Jentic One instance and injected into Authorization at execution time so the agent never sees it.

### Can I retrieve restaurant menus with this API?

The published OpenAPI spec only exposes GET /restaurants and POST /orders. There is no menu, modifier, or item-pricing endpoint. Agents must obtain item details out-of-band - for example from a partner agreement with the restaurant - before submitting an order body.

### What are the rate limits for the Grabbly API?

The OpenAPI spec does not declare rate limits. Limits are enforced at the Grabbly gateway tied to the Authorization key. Cache the /restaurants response for short windows since the list does not change frequently within a session.

### How do I place an order through Jentic?

Search Jentic for 'place a food order', load POST /orders, and execute with a restaurant_id plus items array. The Jentic SDK returns the order confirmation payload so the agent can quote the order id and any returned status back to the user.

### Can I track an order's delivery status with this API?

The current spec does not expose an order-tracking endpoint. Order tracking, if available, is handled outside this OpenAPI surface. For now, the agent should treat the POST /orders response as the canonical confirmation and prompt the user to track via the Grabbly app or notifications.

### Can I limit what my agent is allowed to do with the Grabbly API?

Yes. Because you run Jentic One yourself, you decide which of Grabbly's two operations your agent may call: reading the restaurant list with GET /restaurants, submitting a food order with POST /orders, or both. If you want an agent that only browses and never places orders, grant it GET /restaurants alone, so it cannot reach POST /orders. Since Grabbly takes the order details in the request body rather than a resource id in the path, your rules at the operation level are what control what the agent can actually do.