For platform reviewers

If you are reviewing Layout for a connector directory, read this page first. Everything here links to the detail behind it. If something you need is missing, write to contact@layout.link and we will publish it rather than answer it once in an email.

The connector at a glance

The questions reviewers actually ask

Can a model spend money on its own?

Not without a confirm call, and never outside the limits. order builds a cart and stops. Placing it is a separate confirm that must name that order and the exact total we showed. Our server checks the confirm against the stored cart and refuses a total that does not match, and checks the person's daily limit. Before the card is held, the $50 per order ceiling is enforced. There is no parameter that skips any of this.

A six digit code texted to the person is also required when the order is over $50, when our risk check steps it up, when a code has already gone out for that order, and for an app the person has not given standing consent. The code is bound to that one order at that one amount.

Under that floor, the confirm is the consent. Our server cannot tell whether the person said yes or the host decided they did, and we do not claim otherwise. People agree to this arrangement under the Delegated Spending Authority terms, which treat a confirm from a connected assistant as their authorization. What bounds a confirm the person did not mean is the price lock, the per order ceiling and the daily limit, which defaults to $50. See money controls.

What can the connection reach if a host is compromised?

The order scope covers finding restaurants, reading menus, ordering, and the person's own food preferences. A stolen or misused token can attempt orders, and each one meets the same price lock, daily limit, per order ceiling, risk check and code rules as any other. It cannot read the person's card number, because we do not have it. It cannot change the spending limit, because that is not on this surface.

How is the token bound?

The access token is an RS256 JWT our authorization server signs. We verify the signature against our own JWKS and require both the issuer and the audience to match this resource, so a token minted for anything else is refused. The user identity comes from a claim inside that signed token and is never read from anything the caller asserts. See how the connector works.

Can a user revoke it?

Yes, at account.layout.link and in the iPhone app, one connection at a time or everything at once. Every call checks that the connection is still live, so a disconnect stops a token already in a host's hands on its next call rather than at expiry.

What happens to card data?

It never reaches us. The person's card is entered into Stripe's own fields and kept in Stripe's vault, and we hold a token. Each order is paid with a card Layout holds, issued by Mercury, so the restaurant never receives the person's number either. See card data.

What stops prompt injection from a restaurant's website?

The part of Layout that drives a checkout holds no card and cannot get one without a claim our server signed for a confirmed amount, so text on a page has nothing to talk it into. Around that, content we return to a host model is fenced and labelled as reference material rather than instruction. That prompt level boundary is a default, not a guarantee, and we treat it that way. See untrusted content.

Is there rate limiting?

Yes: per user and per connecting client on every call, a daily allowance and a cooldown on live menu reads, and limits on how many codes can be texted. See limits and availability.

What does Layout log?

Order records, per order traces kept for 120 days, and product analytics without payment details in it. Card numbers and security codes are excluded by construction, not redacted after the fact. See data we store.

Testing it

The connector orders real food from real restaurants with a real card, so we do not hand out an account and suggest you try it: a test order is somebody's lunch sitting on a counter.

The developer platform has a sandbox with scripted test restaurants and sign in test accounts, documented at developer.layout.link. It is reached with sandbox credentials; the public connector itself only reaches real restaurants. For a review of the connector, write to contact@layout.link and we will set up a review account and walk the flow with you while somebody watches the run.

Where we are early

Stated here rather than discovered later. Layout is early. Real orders are placed and paid, with a person watching more of them than will be true in a year. The failure we work hardest to avoid is a confident claim about an order that did not happen, and the honest state of any order is always available to the person, including "we are not sure yet."