All docs
4 min read

Editing

Most submissions you'll never touch — they came in clean, you saw them, you moved on. But sometimes you need to change one. A typo in an email address, a mis-categorised support ticket, a status flip from received to processed after you've handled it.

Submissions are editable. Sparingly.

Why you'd edit

Three legitimate reasons:

  • Correcting typos. A visitor typed florain@example.com instead of florian@. You want the autoresponder retry to land in the right inbox.
  • Flagging status. You've replied to a support submission. Flip its status to processed so the next teammate doesn't double-handle it.
  • Sanitising sensitive data. Someone pasted a full credit-card number into a message field. You want it scrubbed from your backend before backups roll.

Reasons not to edit:

  • Building a workflow on top. Status fields aren't a kanban — use a webhook into your real ticketing system.
  • Faking submissions. Edit doesn't create new rows; for that, just POST to the endpoint.
  • Routinely "cleaning up" payloads. If you're doing this often, the form schema is probably wrong. Fix the form, not the rows.

What you can edit

Payload

Every key in the submission's payload is editable. From the inbox detail panel, click the pencil icon next to any value, type the new value, save. Validation runs against the form's current schema — if you try to set email to not-an-email, we 422 and reject the change.

For complex types:

  • Array fields (multi-checkbox values) — comma-separate in the input.
  • File fields — you can detach a file (removes the bytes too, irreversibly) but you can't upload a replacement via edit. If you need a different file, ask the visitor to resubmit.

Status

The status pill is editable too. Allowed transitions:

From To Effect
received processed Flag handled. No side-effects.
received spam Same as Mark as spam. Moves to spam folder.
spam received Same as Mark not spam. Re-fires notifications, autoresponder, webhooks.
failed received Re-process — re-runs notifications and webhooks.

We don't allow setting failed manually. That's a system-only state.

Metadata

Read-only. You can't rewrite the IP, user agent, AI moderation score, or submitted_at timestamp. If those were wrong at submission time, they stay wrong — those fields exist for forensics, not narrative.

How to edit

From the dashboard

Open the submission's detail panel, click the pencil icon next to a value, type, save. Each edit is a separate write — there's no batch "edit several values then commit" flow in the UI.

From the REST API

PATCH /api/v1/submissions/{submission}
Content-Type: application/json
Authorization: Bearer ...

{
  "payload": { "email": "florian@example.com" },
  "status": "processed"
}

Both payload and status are optional. payload is a partial merge — keys you don't include are unchanged. To delete a payload key, set it to null.

From MCP

update_submission(
  id="01K2M...",
  payload={ "email": "florian@example.com" },
  status="processed"
)

Requires submissions:write ability.

Audit trail

We don't have one yet. Today, an edit overwrites in place — no history, no "edited by" stamp, no diff. If two people on a team edit the same row, you'll see the second person's version with no indication an edit happened.

This is a known gap. A submission audit log is on the roadmap. Until it ships:

  • Treat edits as exceptional. If you find yourself routinely editing rows, automate it via API instead — at least the API access logs capture what happened.
  • Keep a paper trail elsewhere. If sensitive payload edits are part of your compliance posture, log the action in your own audit system before calling our API.
  • Don't rely on edit for "soft delete" of fields. Setting a field to empty string and a real soft-delete look identical, with no way to tell after the fact.

If audit history matters for your use case, hit us up — it's a planned feature and your nudge moves it up the queue.

What's next

← Previous
Bulk actions
Next →
Surveys