Environments and approval
Sandbox works the minute you create an application. Production needs a human yes from us, and while you wait nothing about your sandbox changes.
Two environments, two keys
You get the sandbox key the moment you create an application. The production key is created with it but stays hidden until the application is approved; then you reveal it on the console’s Credentials page. The prefix picks the environment, so there is no flag to set and no way to aim a sandbox key at production by accident.
| Environment | Secret prefix | What happens |
|---|---|---|
| Sandbox | sk_test_ | A cart at a real restaurant is built from the menu Layout holds for it, with no browser, and reaches the ending you ask for. A confirm is simulated: no restaurant receives it, nothing is charged, and the person is never texted. |
| Production | sk_live_ | Real orders, real money, real people. Requires approval. |
Finishing an order in sandbox
A sandbox user can be taken all the way to a placed order, so you can test the whole flow before you have production keys.
| Step | In sandbox |
|---|---|
| Provision | The phone must be a reserved test number, +1 500 555 followed by four digits. Nobody holds these numbers. |
| Verify | Optional in sandbox. verify/start texts nobody, and verify accepts the code 000000. |
| Build | A priced cart from the restaurant’s menu as Layout holds it, with its real items and choices, and no browser. simulate picks the ending and latency the wait. See Sandbox. |
| Confirm | Simulated. No code unless the cart was built with "simulate": "code", or at test_place_code; the code is 000000. REST answers 202 placing with simulated: true. No restaurant receives it and nothing is charged. |
The total you confirm with must still match the cart. A stale total is refused with price_changed in sandbox exactly as it is in production, so a simulated order still proves the cart you built.
Sandbox for OAuth clients
An OAuth client has no key to pick the environment, so the person picks it. A sign-in test account you create on the console's OAuth clients page is sandbox: it connects before approval, only to that application's clients, and its confirms are simulated. Every other person, your own Layout account included, is production.
How approval works
A new application starts under review. Someone here reads it, usually within a business day, and you get an email either way. Nothing to chase, nobody to book a call with.
| Status | Sandbox | Production | What it means |
|---|---|---|---|
| Under review | Works | Refused | The default for a new application. Build against sandbox while you wait. |
| Approved | Works | Works | Production keys are live. Sandbox keeps working alongside them. |
| Sandbox only | Works | Refused | We reviewed it and did not enable production. Your integration keeps running; nothing you built stops. |
| Suspended | Refused | Refused | Both environments are closed. We will have contacted you. |
An approved application is listed in Connectors, the directory of apps built on Layout inside the Layout app. The listing shows the application’s name and logo, your company name and website, and the month it was approved, all from what you entered in the console. A person who connected your app can disconnect it from its listing.
A refused production call
A production key on an application that is not approved is 403 unauthorized, the same body as every refusal. Refused requests, on the Credentials page, shows the reason. See Why refusals never say why.
Going to production
- Build and test against
sk_test_. Nothing about the request shape changes later. - Wait for the approval email, or check the application in the console.
- Reveal the
sk_live_secret on the console's Credentials page and put it in your production config only. - Verify production webhooks with the production signing secret, which the console's Webhooks page shows. Sandbox and production deliveries are signed with different secrets;
X-Layout-Environmentsays which one to use (see Verify the signature).
Read the secret from config and never branch your code on which one you have. The requests are the same. What answers them is not:
| What | Sandbox | Production |
|---|---|---|
| Phone numbers | Only +1 500 555 test numbers. Nothing is texted. | Real numbers only; a test number is refused. Verifying texts the person a code. |
| Test restaurants | test_place_ ids script an outcome. | Find nothing. Every placeId is a real restaurant. |
| Confirm | Simulated, "simulated": true. No code, except at test_place_code. | A real order, charged to the person's card. The person needs a verified number and a card, and a code when one is due. |
sk_live_ out of development, test and CI. The same code that runs a simulation with sk_test_ places real orders and charges real cards with sk_live_. A webhook endpoint receives sandbox events, production events or both, and the default is both. An endpoint left on both also receives production events once the application is approved, so set a development tunnel to sandbox only, or remove it, before then.
Deleting an application
Delete application, in the danger zone of the console’s Application details page, removes the application and its webhooks, and every credential stops working with it. It is a soft delete. To end only a credential, revoke it from the same zone instead. Revoking an environment, or the whole application, also ends the 24-hour overlap of a rotated secret at once.