Sandbox test restaurants

A sandbox build used to drive a real restaurant's site. That made it slow, it could not be told to fail, and it could not run in CI. Sandbox now has test restaurants, the way a payment processor has test cards: name one by its placeId and you get the outcome it scripts, every time.

What changed

• Twelve test restaurants. test_place_carted, test_place_needs_choices, test_place_needs_location and its two branches, test_place_closed, test_place_price_changed, test_place_placed, test_place_failed, test_place_unconfirmed, test_place_challenge and test_place_slow. Sandbox test restaurants lists what each one does.
• Real orders, simulated. Carts, confirm, GET /v1/orders/:id, the event feed and your webhooks treat them as orders, with simulated: true, and the events arrive in seconds.
• Findable. In sandbox, GET /v1/places?query=layout test lists them, up to limit, and POST /v1/menus returns their test menu, with known prices.
• Their own allowance. 10,000 test restaurant builds a day for each developer account. They never draw your sandbox build allowance.
• Fire a test webhook. POST /v1/sandbox/webhooks/fire with your sk_test_ key sends one signed event of any type except order.needs_approval to your subscribed endpoints, optionally describing one of your sandbox orders.

POST /v1/carts
{ "placeId": "test_place_failed", "items": ["latte"], "idempotencyKey": "ci-4812-cart" }

POST /v1/sandbox/webhooks/fire
{ "event": "order.unconfirmed" }

Why it matters

You can test the paths that matter most and happen least: a declined order, an order Layout cannot confirm either way, a price that moved, a cart that takes a while. Your CI can run them on every commit without a restaurant, a browser or a charge.

What to do

Nothing, unless you want them. Point your tests at a test_place_ id with a sandbox credential, and give each run its own idempotency keys. A production credential that names one gets the same answer as for any place that does not exist.

Breaking changes

None.

All changes