Test the full flow

The sandbox is un-metered and never billed, so you can exercise the entire VIP loop against it as many times as you like before you go live. This page gives you a one-command smoke test and the equivalent step-by-step curl calls.

One command

Grab a sandbox Org-API-Key from the developer portal and run the committed smoke script from the monorepo root:

EXPYS_API_KEY=expys_sandbox_... ./scripts/onboarding.smoke.sh

It walks the full loop and exits non-zero on the first failed step:

POST /v1/auth/exchange - mint a member token for a VIP
POST /v1/wallet/credit - fund the VIP with points (server-side)
GET /v1/offers - browse the seeded catalog
POST /v1/interests - register interest, which opens the concierge conversation
POST /v1/redemptions - redeem from that interest
GET /v1/wallet/transactions - read the wallet ledger
GET /v1/conversations - list the member’s concierge conversations
GET /v1/terms - which legal documents the member still owes

Step 5 also asserts the property most worth smoke-testing: the redemption inherits the interest’s conversation rather than opening a second one. A member who spent a week talking to a concierge must not lose that thread the moment they commit.

The VIP journey

The whole arc in order, with the endpoint behind each step and who calls it.

Override EXPYS_BASE_URL or EXPYS_EXTERNAL_USER_ID if you need to.

Step by step

Exchange a member token

Your backend presents the Org-API-Key and an externalUserID; the app never holds the key.

TOKEN=$(curl -fsS -X POST https://api.expys.com/v1/auth/exchange \
  -H "Authorization: Bearer $EXPYS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"externalUserID":"vip-123"}' | jq -r '.accessToken')

Fund the VIP

A points-priced redemption is paid from the VIP’s wallet, so credit some points first (a server-side, machine-only call).

curl -fsS -X POST https://api.expys.com/v1/wallet/credit \
  -H "Authorization: Bearer $EXPYS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"externalUserID":"vip-123","amount":50000,"reason":"demo"}'

Browse, express interest, redeem, and read back

With the member token, browse the catalog, register interest in the first points-priced experience, redeem from that interest, then read the wallet and conversations.Registering interest first is optional — POST /v1/redemptions works on its own — but it is the flow the concierge desk actually runs, because it opens the conversation before any points move.

OFFER=$(curl -fsS https://api.expys.com/v1/offers \
  -H "Authorization: Bearer $TOKEN" \
  | jq -r 'first(.offers[] | select(.pointsPrice != null) | .id)')

curl -fsS -X POST https://api.expys.com/v1/redemptions \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d "{\"offer\":\"$OFFER\"}"

curl -fsS https://api.expys.com/v1/wallet/transactions -H "Authorization: Bearer $TOKEN"
curl -fsS https://api.expys.com/v1/conversations -H "Authorization: Bearer $TOKEN"

Concierge replies in the sandbox

You can test the concierge loop end to end without anyone on our side being paged. A message sent into a sandbox conversation is never forwarded to our Ops team; instead a sandbox concierge bot replies automatically, and that reply streams back to you over GET /v1/conversations/{id}/stream exactly like a human concierge message. See Conversations for the streaming details.

None of this touches billing or pages a human - the sandbox is free and isolated. When you go live, the same calls run against your own catalog and a real concierge. See Going live.

Getting started

Catalog and pricing

Booking and members

Wallets and points

Concierge

Server-side operations

Reliability and reference

Test the full flow

One command

The VIP journey

Step by step

Concierge replies in the sandbox

​One command

The VIP journey

​Step by step

​Concierge replies in the sandbox

One command

Step by step

Concierge replies in the sandbox