Docs corrections
We read every reference page against the code that runs it and corrected about 140 statements. Most fill in limits and refusals that were not written down. The ones below change what an integration should do.
What to do
- Totals. An order's and a webhook's
total_minoris the restaurant's total without Layout's fee. Show the cart'stotalMinorbefore confirm and the order'samounts.charged_minorafter. Never confirm withtotal_minor. See Confirm. - A failed order. Do not tell the person "nothing was charged" on every failure: a pending hold can show for a while. Retry only on the failure codes that say a retry can work. See Failure codes.
- When a code is needed. A build grant's confirm needs the person's code when Layout would ask for one anywhere else, and on the first order of a person who connected before Layout asked for their agreement at connect. Read
codeReasonon the cart. See When the answer is code_required. - Sandbox codes. Sandbox asks for a code only at
test_place_code, whose code is000000. See Sandbox. - Unconfirmed orders over MCP. The placement poll answers
unconfirmed, neverfailed. Never retry it. See MCP. - Building over MCP. A
buildneedsqueryand a restaurant name withnearorgeo; aplaceIdalone is refused. A build session cancels only with anorderId. See MCP tools. - Location.
neartakes a city or town name, and distances are measured from its centre, not from the person. A neighbourhood or landmark is usually not placed: send coordinates. See Finding the nearest store. - Silent sign-in.
prompt=nonecan also answerunauthorized_clientorinvalid_target, which showing the button will not fix, and always answersconsent_requiredto alocalhostredirect. See Returning people. - Testing with your own account. Before your application is approved, your own Layout account cannot connect to your client. Test with a sign-in test account. See Authentication.
Breaking changes
None. Nothing in the API changed with these corrections; the pages now describe what it already does.