> Production API availability: use /api/v1/help?view=guides and the resource operations catalog before following a recipe. Some localhost capabilities are not deployed yet; an absent operation is unavailable.
Identify the receiver
A form may submit to Antsand or to a generated site's local endpoint. Read the configured action, method and context. Do not infer the receiver from the domain where the form is displayed.
Follow storage separately from delivery
A generated membership form can change site-local state while using a central service to deliver email. Email delivery and data storage are separate responsibilities.
For each form, identify the receiver, the stored record, the workflow trigger and the delivery service. Keep passwords, reset tokens and private fields out of public source projections and logs.
Diagnose the connection
Use the Forms connection diagnostics to locate pages and sections that reference the form. Inspect the HMVC action it targets and whether that action is present.
A configured route is useful evidence, but not proof that the submission succeeds. Test the request, validation response, storage effect and intended workflow with designated test data.
Verify a workflow
Check the administrator notification and subscriber action separately. For an ebook email, verify the recipient, approved attachment, successful delivery and duplicate-submission behavior.
Do not enable a new workflow by copying another site's credentials or assuming its sender configuration applies to this site.
Follow one submission end to end
Start with the page and section showing the form. Read the mapped form identity and the actual method and action rendered in HTML. Then inspect the receiving action's contract and the database it writes.
For a generated member reset flow, the member identity and reset state belong to the generated site's account system. Central email delivery may carry the message, but it should not become a second account database. For a central newsletter form, the central Forms workflow can process the submission and delivery actions.
Do not infer which design is in use from the button label. The receiver, action contract and storage configuration determine that.
Test the outcome
- Submit valid data and verify the expected record and response.
- Submit invalid data and confirm it is rejected without a misleading success message.
- Test CSRF and session expiry on session-bound actions.
- Check a different account cannot modify another account's state.
- If delivery is part of the workflow, inspect both the delivery result and the submission record.
- Repeat after regeneration to confirm the configuration survives.
A notification email proves delivery of that message; it does not prove every retry, attachment policy or account boundary. Record those checks separately.
See HMVC and sections and validation.