resy-fpx

name

resy-fpx

description

Query and act on Resy (resy.com restaurant reservations) from a shell without running the resy-mcp server — search venues, check slot availability, book/cancel reservations, and manage favorites/Priority Notify with curl against api.resy.com, using the fpx CLI (@fetchproxy/cli) only for the one-time token bootstrap when you have no RESY_EMAIL/RESY_PASSWORD. Use when you want Resy data or actions without the MCP, in a script, or on a machine where the MCP isn't installed.

Resy via curl (+ one-time fpx bootstrap)

Resy has no public API — resy-mcp calls the same api.resy.com endpoints the resy.com web app calls, all of which are reachable with plain curl; nothing here needs a bot-wall bypass. The browser bridge (fpx) is only needed to mint an auth token when you have no email/password on hand — after that, every actual call (search, slots, book, cancel, favorites, notify, profile) is a direct curl with the token in a header. This mirrors resy-mcp's own "Pattern B": bridge the one auth call, then go direct for the hot path (see src/client.ts / src/auth-fetchproxy.ts in the resy-mcp repo).

Step 1 — get a token (pick ONE path)

Path A — you have Resy credentials (preferred, no browser needed):

curl -s 'https://api.resy.com/3/auth/password' \
  -H 'Authorization: ResyAPI api_key="VbWk7s3L4KiK5fzlO7JD3Q5EYolJI7n5"' \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  --data-urlencode "email=$RESY_EMAIL" \
  --data-urlencode "password=$RESY_PASSWORD" \
| jq -r '.token // .id.token // .auth_token'

The api key above is Resy's public web-app key (baked into resy.com's own JS, not a secret — see src/client.ts). Save the returned token as $RESY_TOKEN.

Path B — no credentials, only a signed-in resy.com browser tab:

One-time setup:

npm install -g @fetchproxy/cli            # provides `fpx`
fpx profile add resy --domain resy.com
fpx pair -p resy                          # prints a pair code → approve in Transporter

Then bootstrap the token through the tab (this replicates the one call resy.com's own JS makes to refresh its in-memory token — the HttpOnly session cookies authenticate it):

fpx post-json 'https://api.resy.com/3/auth/refresh' '{}' -p resy \
  | jq -r '.token'

Save it as $RESY_TOKEN. fpx is not used again after this — every call below is curl.

Step 2 — call the API directly with the token

Every authenticated request needs this header set (see SPOOF_HEADERS + buildHeaders in src/client.ts):

RESY_API_KEY='VbWk7s3L4KiK5fzlO7JD3Q5EYolJI7n5'   # override if Resy rotates it
curl -s '<url>' \
  -H "Authorization: ResyAPI api_key=\"$RESY_API_KEY\"" \
  -H "x-resy-auth-token: $RESY_TOKEN" \
  -H "x-resy-universal-auth: $RESY_TOKEN" \
  -H 'Origin: https://resy.com' \
  -H 'Referer: https://resy.com/' \
  -H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36' \
  -H 'Accept: application/json, text/plain, */*'

POST/DELETE bodies are application/x-www-form-urlencoded (--data-urlencode), except venue search which sends a single struct_data field containing JSON. All 14 request/response shapes, copy-pasteable, are in references/resy-api.md.

The one rule: resolve venue → slot → book_token before booking

Booking is a 3-hop chain, same as resy_book's internal flow:

1. POST /3/venuesearch/search or GET /4/find → config_token for the slot you want.
2. GET /3/details?config_id=<config_token>&day=&party_size= → book_token.value (expires fast — fetch it right before booking).
3. POST /3/book with book_token + struct_payment_method (get a payment id from GET /2/user if you don't already have one).

Token lifetime

Resy tokens are opaque with no published TTL and no separate refresh token. If a call 401s (or 419s, or 500s with an auth-shaped message), just re-run Step 1 to mint a fresh one — there's no incremental refresh.

Exit codes (fpx, Path B only)

• 0 — success.
• 2 — bridge unavailable: extension not connected or pairing pending → fpx pair -p resy, confirm a resy.com tab is open.
• 3 — bot wall: shouldn't happen on the bootstrap call, but if it does, refresh the resy.com tab and retry.
• 4 — upstream non-2xx (e.g. not actually signed in — sign into resy.com in that tab first).

Notes

• This is your own Resy account — write calls (book, cancel, favorite, notify) mutate real reservations/subscriptions. There is no dry-run at the curl layer (the MCP's confirm-gated preview is an MCP-side convenience); read back with a list call before/after a write if you want to verify it landed.
• fpx health -p resy shows bridge connection state if Path B's bootstrap call fails.
• This project is developed and maintained by AI (Claude).