The short answer
A catch-all address plus a database row works while your agents only receive mail, and it starts to break when they reply, sign up for services and multiply. A real inbox per agent, or per customer, gives each one its own stored mail, threads, key, ID and sending record, so nothing has to be reassembled from one shared pile. With Pidgeon inboxes are unlimited on every plan, and one call at your customer's signup creates theirs.
One question decides it
Ask what the agent will do with the address.
If mail only needs to arrive somewhere, such as invoices for a parser or stray mail to a domain, route it. One destination, a lookup on the local part, nothing to provision. That design is cheap and correct.
If something will reply from the address, sign up with it, or be held to what it sent, give it an inbox. Each of those three is a job a row in your table cannot do on its own, and the sections below are why.
When the agent replies
An agent that answers has to send from the address the mail arrived at, keep the conversation in one thread and find it again when the next reply comes. With a catch-all, your table is the only thing that knows acme@ exists, so storage, threading and history are all code you write on top of it.
In Pidgeon a catch-all is a destination only: nobody can put *@yourdomain.com in a From: line, and an address that sends has to be one that exists. An inbox is that address. Its mail is stored, threaded and searchable until you delete it, and a person can open the same conversation in the dashboard or a mail client when the agent should not be the one answering.
When it signs up with the address
An agent that signs up for a service uses its address as an identity. The verification code, the password reset and every receipt after that arrive there for as long as the account lives, so the address has to belong to that agent next month as well as today.
A catch-all also accepts mail for every local part nobody ever created. A typo or a guessed address never bounces, the sender believes it reached someone, and your code has to decide for each message whether it belongs to anyone. A real address either exists or it does not.
There is also the other side: whoever receives the agent's mail. Every agent address in Pidgeon has an agent card, signed and checkable by anyone with the public verifier, which says which domain stands behind the agent and who it acts for. An address that exists only as a row in your table has no card, so a recipient has nothing to check.
When there are a hundred of them
One destination means one credential that reads everything. An agent that should see only its own mail sees every agent's, and one leaked key exposes all of them. In Pidgeon a key created with identity_ids reaches those addresses and nothing else, and a key can mint narrower keys but never wider ones.
All of a catch-all's mail also leaves from one domain on one sending record. When one customer's agent mails a list of dead addresses, the bounces count against the domain every other customer sends from, and a row cannot be paused, measured or isolated on its own. Put customers in separate pods and each has its own sending reputation. Each address also gets its own send policy (open, reply_only or list) and a per-recipient cooldown that, by default, stops a looping agent at the fourth new message to the same person in ten minutes.
The middle ground: routing rules
Not every address needs to be an inbox, and not every catch-all needs to be all-or-nothing. Pidgeon has a catch-all, behind two switches: a catch_all routing rule naming where the mail goes, and catch_all_enabled on the domain.
Between the two are routing rules. An address rule sends hi@ into the hello@ inbox, and that inbox may then answer from hi@. A pattern rule takes every address that starts with a prefix, so inv- catches inv-2026-0001@ and inv-acme@ alike. A rule can also point at a webhook, which stores nothing. Every plan includes them, 25 per domain on Free, and they need a domain you connected.
Making one at your customer's signup
The usual moment is your own signup handler: a customer registers, and their agent gets an address before the welcome screen loads. If you serve many customers, make a pod for each one, with the address and a key that reaches only that pod, in one call:
curl https://pidgeon.ai/api/v1/pods \
-H "Authorization: Bearer $PIDGEON_ADMIN_KEY" \
-H "Content-Type: application/json" \
-H "Idempotency-Key: signup-cus-4417" \
-d '{
"name": "Acme Ltd",
"client_id": "cus-4417",
"address": { "address": "acme@yourapp.pidgeon.email", "type": "agent" },
"key": { "access": "send" }
}'
All three are made or none is. The Idempotency-Key makes a retried signup safe: the same key and body return the same pod, address and key rather than a second set. The key's secret is shown once, so a replay returns "token": null; store it on the first answer, or rotate the key if that answer was lost. client_id is your own id for the customer, so you can find the pod later without a mapping table.
If you do not need per-customer reputation, POST /v1/identities with an address and "type": "agent" creates the inbox alone.
Inboxes are unlimited, but creating them is paced: a Free account creates up to 20 addresses a day, and a paid account what its trust tier allows in 24 hours (150 at the normal tier). Pods are counted per plan, from 3 on Free to unlimited on Enterprise. The numbers are on limits.
Start
The addresses guide covers inboxes, routing rules and the catch-all. Pidgeon for platforms has the full provisioning and teardown sequence, and pods explains the reputation boundary. To check an agent's card, paste one of its emails into the verifier.