How to collect responses from a Claude Artifact form
Claude will happily write you a survey, a feedback form or a booking request in a single message, and the result looks and behaves the way you asked. The part that is missing is the other half of a form: a place for the answers to land. This guide explains why that gap exists, sets out the three sensible ways to close it, and then shows the Sentway route in full.
Why the responses go nowhere by default
A form in a browser is only markup until something receives it. The submit event either posts to a server address or it does nothing. An artifact is generated as a self contained page, so unless you give the form a destination the answers exist for as long as the tab is open and then they are gone.
This is not a flaw in how the page was written. It is the normal division of labour: one thing renders the form, another thing stores what people type into it. You are choosing the second thing.
Option 1: point the form at a form backend
Services such as Formspree give you an endpoint URL to put in the form's action attribute. Submissions are stored against that endpoint and you read them in the service's own dashboard or forward them on.
This is the sensible choice when you want to keep hosting the page wherever it already lives and the only thing you are missing is somewhere for the submission to arrive. You keep full control of the markup, and the change to the page is one attribute.
Option 2: use a dedicated form product
Products built specifically for forms and surveys give you a question editor, logic between questions, and reporting designed around responses. You either send people to their hosted form or embed it in your page.
This is the sensible choice when the form itself is the deliverable and the builder and the reporting are what you actually want. If you are running the same survey repeatedly and you care about the response analytics more than the page around it, reach for one of these.
Option 3: publish the page through Sentway
Sentway serves the page your AI wrote on its own address and captures the form submissions natively, with no endpoint to configure. Submissions are stored against the site and against the visitor who sent them, and your AI can read them back over MCP in the conversation where the page was designed.
This is the right fit when the page itself should stay exactly as your AI built it, when you want an access rule in front of it, and when you want to ask your AI what the answers say rather than exporting them somewhere to read alone.
The Sentway workflow, exactly
Give every field a meaningful name attribute. The name is the label the answer carries into the dashboard, the notification email and the tool response, so use something you will recognise a month later. Radio groups record the chosen value once. Checkboxes record each ticked value.
Publish the page. Your AI creates the site, saves the page and publishes it, and Sentway serves it with the SDK injected. The SDK intercepts the form's submit event on the served page and records the named fields.
Read the responses back with get_submissions. That tool returns form submissions specifically. Page views, active time and the rest of a visitor's activity are separate readbacks, so a visit is never counted as a response and a response is never inferred from behaviour.
1. Ask your AI for the form, and tell it to give every field a meaningful name attribute.
2. Ask it to publish the page to Sentway and hand you the public URL.
3. Send the URL to the people whose answers you want. Add an email gate first if you need to know who each answer came from.
4. When responses have arrived, ask your AI to read the submissions back and summarise them.
When Sentway is the wrong answer
If all you need is a normal form and you already like a dedicated form product, use it. Sentway earns its place when the page around the form matters, when access to it needs a rule enforced on the server, or when you want the AI that wrote the questions to be the thing that reads the answers. A plain contact form on an existing site is not that.
Build me a customer feedback form with fields for name, email, a 1 to 10 satisfaction score, a multi select question about what they value most, and a free text question about what we should improve. Give every field a meaningful name attribute. Publish it to Sentway and tell me the public URL. Once responses start arriving, read the submissions back and summarise the answers for me.
Produces: A published feedback form on its own Sentway address, with every answer captured against the site and readable by the same AI that wrote it.
Do I need to add an action URL or a form endpoint to a Sentway page?
No. Sentway captures the submit event on the served page itself. A form with no action attribute is captured in exactly the same way as one that has one.
What happens if a field has no name attribute?
It has nothing to be recorded under, so it is not captured. The name attribute is the whole contract, which is why it is worth telling your AI to set meaningful names when you ask for the form.
Is a page view counted as a response?
No. Form submissions and visitor activity are separate. get_submissions returns what people typed and sent. Views, active time and page level activity come from the analytics and visitor readbacks instead.
Can I still use Formspree with a page published on Sentway?
Yes. Nothing stops a form from posting to an external endpoint, and Sentway does not modify your markup beyond injecting its SDK. Most people do not need both.