Angie Eats Partner API

There is no self-service signup. An Angie Eats engineer mints your key on a partner record naming your company, a technical contact, the market you're cleared to trade in, and — for a single-chain integration — the specific restaurants you may reach. Email partners@eats.heyangie.ai with your company name, the market, and the narrowest set of scopes that does the job (see Scopes).

You'll be sent the plaintext key exactly once. The platform stores only a SHA-256 hash of it — there is no "reveal key" screen, because there is nothing to reveal. If you lose it, ask for a new one; the old one gets revoked.

Send the key as a bearer token:

Authorization: Bearer zpk_live_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

or, if a custom header is easier for your HTTP client than Authorization:

X-Api-Key: zpk_live_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Both were verified to work identically against the live API.

Every key is granted one or more scopes, and every route requires exactly one. A key missing the scope a route needs gets a 403 that names the scope — see Errors. Read and write are always separate scopes: the commonest integration is a menu sync that only ever reads, and the second commonest is a till that only ever writes availability. Granting both because it's convenient turns a single leaked key into fraudulent menu edits, not just a data leak.

All three live under /api/v1/partner and require a valid key with the scope noted.

curl -s https://eats.heyangie.ai/api/v1/partner/restaurants \
  -H "Authorization: Bearer $ANGIE_EATS_KEY"

{
  "restaurants": [
    {
      "id": 25,
      "slug": "demo-kitchen",
      "name": "Demo Kitchen",
      "market": "US",
      "currency": "USD",
      "timezone": "America/Chicago",
      "accepts_orders": true
    },
    {
      "id": 26,
      "slug": "sakura-sushi-25435",
      "name": "Sakura Sushi 25435",
      "market": "US",
      "currency": "USD",
      "timezone": "America/Chicago",
      "accepts_orders": false
    }
  ]
}

curl -s https://eats.heyangie.ai/api/v1/partner/restaurants/25/menu \
  -H "Authorization: Bearer $ANGIE_EATS_KEY"

{
  "restaurant": {
    "id": 25,
    "slug": "demo-kitchen",
    "name": "Demo Kitchen",
    "currency": "USD",
    "currency_minor_units": 2,
    "timezone": "America/Chicago"
  },
  "menu": [
    {
      "id": 3,
      "name": "Pizza",
      "items": [
        {
          "id": 5,
          "name": "Margherita",
          "description": "San Marzano, fior di latte, basil.",
          "price": 1295,
          "is_sold_out": false,
          "sizes": [
            { "id": 1, "name": "10\"", "price": 1295 },
            { "id": 2, "name": "12\"", "price": 1695 }
          ],
          "modifier_groups": [
            {
              "id": 6,
              "name": "Choose a base",
              "selection_mode": "single",
              "min_selections": 1,
              "max_selections": 1,
              "is_required": true,
              "modifiers": [
                { "id": 14, "name": "Classic", "price_delta": 0 },
                { "id": 12, "name": "Thin crust", "price_delta": 500 }
              ]
            }
          ]
        }
      ]
    }
  ]
}

curl -s -X POST https://eats.heyangie.ai/api/v1/partner/restaurants/25/availability \
  -H "Authorization: Bearer $ANGIE_EATS_KEY" \
  -H "Content-Type: application/json" \
  -d '{"items":[{"id":39,"is_sold_out":true},{"id":999999,"is_sold_out":true}]}'

{ "updated": 1, "ignored": [999999] }

Every refusal is a JSON body shaped {"message": "..."} (422 additionally carries an errors object keyed by field). This table is exhaustive for the partner surface today.

A wrong key, a revoked key, and an expired key look identical

On purpose. If a revoked key said "revoked" and a wrong key said "invalid", anyone probing with random strings could tell which guesses were real keys merely turned off. All three get the same message — captured live:

$ curl -s .../partner/restaurants -H "Authorization: Bearer zpk_live_wrong..."
{"message":"That API key is not valid."}

$ curl -s .../partner/restaurants -H "Authorization: Bearer $A_REVOKED_KEY"
{"message":"That API key is not valid."}

$ curl -s .../partner/restaurants -H "Authorization: Bearer $AN_EXPIRED_KEY"
{"message":"That API key is not valid."}

"Outside your grant" and "doesn't exist" both return 404

A restaurant that exists but isn't in your grant is indistinguishable from one that was never real — otherwise a partner could enumerate the platform's full restaurant list by watching which ids return 403 versus 404.

Each key has its own ceiling — 60 requests per minute by default, keyed on the credential, not your IP or your partner account. A busy integration behind one NAT gateway isn't throttled as one caller, and a runaway retry loop in staging can't burn through your production ceiling — they're different keys. Ask Angie Eats for a higher ceiling up front if your traffic profile needs one.

HTTP/1.1 429 Too Many Requests
Retry-After: 59

{"message":"Rate limit of 3 requests a minute reached."}

Every price — price, sizes[].price, and price_delta — is an integer number of the currency's smallest unit, alongside currency (ISO 4217) and currency_minor_units (how many decimal places that currency uses, 0–4, carried on every response so you never hardcode it).

Do not divide by 100 and prepend a currency symbol — that's correct for USD by accident and wrong the day a market with a different currency is added. The correct rendering:

displayed = raw_price / (10 ** currency_minor_units)

then format displayed with your own platform's currency formatter (in JavaScript, Intl.NumberFormatwith the currency code) — only your side knows the reader's locale.

The current and only version is v1, in the URL path. Within it, Angie Eats commits to:

• No field is removed and no field changes meaning without a new version.
• New fields may be added to any response at any time — your integration must ignore fields it doesn't recognize.
• New endpoints and new scopes may be added without a version bump.
• A breaking change ships as v2, with v1 kept running for a publicized deprecation window. There is no v2 today.

1. 1. Get a key.

   Email partners@eats.heyangie.ai with your market and menu:read (and menu:writeif you'll report sold-out items). Save the zpk_live_…string somewhere real before you close that message — it won't be shown again.

2. 2. List what you can see.

   TerminalCopy

   curl -s https://eats.heyangie.ai/api/v1/partner/restaurants \
     -H "Authorization: Bearer $ANGIE_EATS_KEY"

   A 401 usually means the header is missing its space (Bearer <key>). An empty restaurants array on a 200 usually means your grant is scoped to a list that doesn't include anything active — ask Angie Eats to confirm it.

3. 3. Pull one restaurant's menu.

   TerminalCopy

   curl -s https://eats.heyangie.ai/api/v1/partner/restaurants/25/menu \
     -H "Authorization: Bearer $ANGIE_EATS_KEY"

   Render one price correctly before writing anything else — see Money first.

4. 4. If you have menu:write, mark one item sold out and confirm it sticks.

   TerminalCopy

   curl -s -X POST https://eats.heyangie.ai/api/v1/partner/restaurants/25/availability \
     -H "Authorization: Bearer $ANGIE_EATS_KEY" -H "Content-Type: application/json" \
     -d '{"items":[{"id":<item id from step 3>,"is_sold_out":true}]}'

   Check updated matches what you sent and ignored is empty, then re-fetch the menu to confirm is_sold_out: true. Flip it back when you're done testing.

5. 5. Handle the two things that happen in production and never in a demo.

   A 429 — back off using Retry-After, never hot-loop. A non-empty ignoredon a bulk write — log it, it means your catalogue and Angie Eats's have drifted on at least one item, not that the call failed.

• orders:write

  Placing an order on a customer's behalf (a till, an aggregator).

• orders:read

  Reading order status (a KDS, a reporting tool).

• orders:advance

  Advancing an order through the kitchen (accept, ready, complete) as a partner system.

• delivery:read

  Delivery zone and fee lookups for a partner's own checkout.

• webhooks:manage

  Webhooks — a push notification when an order or menu changes. There is no subscription system behind this scope yet; poll the GET endpoints above if you need to know about changes today.