App forms: how a sandboxed app still reaches its owner
Apps that Anticode's model writes run in a sandbox with no network at all, which raises an obvious question: how does the enquiry form inside one reach anybody? Through one function, anticode.send. The app hands the fields to Anticode's own runner on the page around it, and the runner sends them into the same pipeline, checks, inbox and connectors as a published page's forms.
Why the app can't post on its own
An app build is a whole program written by a model: a game, a tool, a planner, a small shop front. Anticode runs it inside a sandboxed frame with an opaque origin and a policy that allows no connections and no form posts. Nothing in the app can fetch a URL or submit a form to a server, so nothing it holds can leak, even if the model wrote something careless. The app sandbox page covers that in full. A normal HTML form that posts would simply fail there, and the code gate flags one before the app is shown.
The one exit: anticode.send
Inside the app, window.anticode.send(form, fields) sends a form to the site's owner. The model is told to use it for every contact, enquiry, booking and newsletter form, and to let any other form (a calculator's inputs, a search box) work inside the page only. A call looks like this in practice:
- The app handles the form's submit event and stops the browser's own submission.
- It calls
anticode.sendwith the form type and either the form element itself or an object of text values whose names match the fields. - It disables the submit button while the call is in progress.
- It gets back
{ ok, title, message }. The call never throws. On success the app swaps the form for a thank-you state; otherwise it shows the message beside the form and keeps what the visitor typed.
| Form | Fields it needs | Notes |
|---|---|---|
| contact | name, email, message | Any extra fields, such as a budget or a preferred date, are added to the message as labelled lines |
| booking | service, day, time, name, phone, email | The day is a date from tomorrow up to 120 days ahead; the time is 24-hour. Each service, day and time can be booked once |
| subscribe | A newsletter sign-up |
What happens between the app and your inbox
The app passes the fields up to the page around it by message. That page is Anticode's runner, a fixed script served from the site's own address, and it checks the fields again (a known form type, at most 30 fields, short plain-text names and values) before doing anything. It sends one form at a time, a couple of seconds apart, and gives up with a clear message if nothing comes back in 30 seconds. Then it posts to the site's own form inbox, without cookies.
From there the request is treated exactly like a form on a published page. The server checks it came from the site, applies per-visitor and per-site rate limits, validates the fields, refuses a booking slot that's already taken, and stores the submission sealed. It then reaches your email and any form connectors you've switched on, such as Slack or Google Sheets, and appears with your other form submissions. If you've attached a site function to that built-in contact, booking or newsletter form, it runs for the app's sends too (on a booking, after the slot check); whether the app shows the function's message to the visitor depends on how it was written, so ask for it and test it. The free plan's monthly allowance applies too: beyond it, submissions are kept but never sent to your email or connectors, not even after an upgrade, which only makes them visible in the inbox.
In the builder's preview
While you're building, nothing leaves the page. anticode.send answers with success and a note that nothing is sent from the preview and that once the site is published the form reaches its owner. That lets you click through the thank-you state without filling your own inbox with test enquiries. To try a real send, publish and use the live address.
What it changes about publishing
- The security baseline counts it. An app that calls
anticode.sendcollects data, so the account owner and the person publishing need two-factor sign-in on before it can be published. - The security report says so. The site's public report lists the app's form as a post to its own inbox, sent by Anticode's runner.
- The checks look for stray forms. The app code gate fails any form that posts somewhere on its own, and the model fixes it in its repair pass.
Limits
- Three form types only. Contact, booking and newsletter. There's no way for an app to send other data to a server, store it in a database or read it back.
- Fixed booking rules. Bookings follow the same rules as page bookings: no deposits, no recurring slots and no calendar sync.
- No files. Fields are text; uploads aren't sent.
- Data the visitor keeps. Anything else the app saves stays in that visitor's own browser storage, not with you.
Questions people ask
How do I send form from AI-generated app code to my inbox?
Ask for a contact, booking or newsletter form when you build the app. The model wires it to anticode.send, and once the site is published each submission reaches you by email and in Anticode.
Why didn't I get an email when I tested the form?
In the builder's preview nothing is sent on purpose. Publish the app and send the form from the live site.
Do app forms work with Slack, Sheets and the other connectors?
Yes. They go through the same submission pipeline as page forms, so every connector you've switched on receives them.
Can the app add its own fields to a contact form?
Yes. Fields beyond name, email and message are added to the message as labelled lines, so nothing the visitor typed is lost.