Features

Built like the rest of your stack.

Postbox is built on a simple premise: a form is a contract between a submitter and a system. The schema defines the terms. The endpoint is the signature. Everything else — validation, spam filtering, translation, routing — is the enforcement layer. We didn't start with a UI and bolt on an API. We started with the contract and let every client — browser, curl, agent — hold it the same way.

That decision cascades into everything below. Self-documenting endpoints. Schema versioning that never breaks old integrations. A pipeline that runs after submit, not before. Agent access through MCP and skills. Here's how it all fits together.

01 / The contract

A form is a contract.

Most form tools give you a UI with a POST endpoint bolted on the back. Postbox inverts that. You define the schema (fields, types, rules) and get back an endpoint URL. The schema is the intent. The URL is the interface. A browser form, a curl script, an autonomous agent. All three hold up the same contract.

This matters because contracts don't care about the client. Your marketing team builds a landing page form. Your mobile app submits to the same endpoint. Your agent creates a new form while you're asleep. Every client gets the same validation, the same spam protection, the same routing. The contract is the source of truth, not the UI.

endpoint
/f/contact
02 / Self-documenting endpoints

One URL. Two audiences. Same contract.

Every Postbox endpoint knows what it is. Send a GET with Accept: application/json and it tells you its schema. Send a GET with Accept: text/html and it renders human-readable documentation. POST to it and you submit data. No SDK. No docs lookup. The endpoint is the documentation.

This eliminates an entire category of integration friction. Your agent doesn't need to read separate docs to understand what fields a form accepts — it asks the endpoint directly. Your frontend developer doesn't need to sync with the backend team on field changes — the endpoint reflects the current schema in real time. When the contract changes, the documentation changes with it. Automatically. Instantly.

GET /f/contact
accept: json
{
  "name": "Contact",
  "method": "POST",
  "fields": [
    "email",
    "message"
  ]
}
accept: html
Contact
email email · required
message string
POST to /f/contact
03 / Versioning

Schemas evolve. Old URLs never break.

Every schema change produces a new endpoint URL. The old one keeps working forever, validated against the schema it was born with. Your three-year-old contact form keeps collecting submissions even after you've redesigned the fields twice. Integrations never silently break. No migration scripts. No deprecation emails. No 3am pages.

Immutable endpoints mean you can iterate fearlessly. Add a new required field to your signup form without breaking the mobile app that still sends the old payload. Run A/B tests with different schema versions on different landing pages. Sunset an old form gradually instead of coordinating a hard cutover. Each version is a snapshot in time, and every snapshot stays alive as long as something is still pointing at it.

v1
/api/abc123/f/contact
jan 2024
live
v2
/api/xyz789/f/contact
mar 2025
live
v3
/api/lmn456/f/contact
apr 2026
live
04 / The pipeline

What happens after submit is the actual product.

Most form tools stop at "data received." Postbox is just getting started. Every submission runs through a pipeline. Schema validation. Spam detection. Language detection and translation. Smart replies drafted from your knowledge base. Routing to the destinations you care about. All async. All opinionated. All built once, so you don't have to build any of it.

The pipeline runs in the background, so submitters always get a fast 201 response. Each stage is toggleable per form. Run validation and spam on your public contact form. Add translation for your global waitlist. Enable smart replies for support tickets. Skip everything except routing for internal tooling. You configure the pipeline once, and every submission flows through it automatically.

{ name: "alice", email: "alice@example.com", message: "hey" }
validate
filter
translate
reply
route
✓ processed in 1.2s
05 / Submissions, read back

Submissions are not data. They're a conversation.

Data sitting in a dashboard waits for you to do something with it. Postbox doesn't make you do the reading. Connect our MCP server to your agent and ask the questions you actually care about. What's the feedback looking like? What are people complaining about? Draft a reply to the angry one. The submissions read themselves back.

This flips the model from "collect then analyze" to "ask and receive." Your agent can list submissions, filter by sentiment, summarize themes across hundreds of entries, translate foreign-language feedback, and draft contextual replies using your knowledge base. You don't export to CSV. You don't build dashboards. You just ask.

What's the feedback looking like?
👤
🤖
12 so far, average 4.2. Three said export is slow. Two want mobile dark mode. One 1-star on settings. The rest are compliments on the new design.
Draft a reply to the 1-star.
👤
🤖
Draft ready. Apologetic, points them to settings at /app/settings. Want to review before I send?
06 / Honeypots

Spam traps that trap spam, not your agents.

Honeypot fields are old magic. Invisible inputs that bots fill and humans don't. Postbox does them properly. You mark a field as a honeypot in the schema, it gets validated on submission, and it's automatically omitted from the discovery endpoint. Agents asking your form what it accepts never see the honeypot. Bots blindly filling every field still do. The trap catches what it's supposed to.

This is the difference between bot protection that breaks your integrations and bot protection that only targets bots. Honeypots require no JavaScript, no CAPTCHA widgets, no user friction. They just work. And because they're schema-native, you can add them to any form in seconds without touching your frontend code.

Contact
3 fields
field
type
owner sees
agent sees
email
email · required
visible
visible
message
string
visible
visible
website 🍯
honeypot
visible
hidden
07 / Idempotency

Retry-safe by default.

Every submission endpoint accepts an Idempotency-Key header. Include one (typically a UUID) and if you retry the same submission, you get the original result instead of a duplicate. Safe networks are rare. Retries happen. Duplicate submissions shouldn't.

POST /f/contact 201
key: a1b2c3d4
POST /f/contact 200
key: a1b2c3d4
submission
sub_xyz
08 / Destinations

The work nobody wants to write twice.

Submissions fan out wherever you need them. Webhooks with HMAC-SHA256 signatures and automatic retries. Discord rich embeds. Slack Block Kit messages. Auto-disabled after three failures, with an email to you. The boilerplate every form tool reinvents, written once, done properly.

Webhooks include the full submission payload plus metadata, signed with a per-destination secret so you can verify authenticity. Retries use exponential backoff with jitter. Discord and Slack destinations format submissions as rich embeds with proper color coding and action buttons. If a destination fails repeatedly, Postbox pauses it and notifies you instead of spamming a broken endpoint. Set it up once, and your data flows to the right place forever.

new submission
webhook
signed · retried
discord
rich embed
slack
block kit
Features FAQ

The details that matter.

Does Postbox host the form UI for me? +
We give you the endpoint and schema. You build the UI however you want — React, Vue, plain HTML, a mobile app, or even no UI at all if your agent handles submissions. For quick testing, every endpoint also renders a basic HTML form when visited in a browser with Accept: text/html.
What field types are supported? +
String, number, boolean, email, date, enum, and honeypot. Each field supports rules like required, min/max length, regex patterns, and allowed values. Custom validation rules are on the roadmap.
Can I use my own OpenAI or Claude API key? +
Not currently. AI features run through our managed infrastructure so we can optimize prompt engineering, caching, and cost across all users. This keeps pricing predictable — you pay per action, not per token. If you have specific compliance needs, contact us.
How fast are webhook deliveries? +
Usually under a second from submission to webhook dispatch. The pipeline (validation, spam, translation) runs async, so the submitter gets an instant 201 while the background work happens behind the scenes. Webhooks include a 5-second timeout with exponential backoff retries up to 3 attempts.

Built this way on purpose.

None of this is magic. It's just a lot of small decisions made in the same direction. Treating forms like APIs. Treating agents like first-class clients. Treating the work after submit as the actual job. Come see for yourself.