The product
Email you own, and can build on
Mailboxes for the people, addresses for the software, one domain and one account. Not a suite you rent seats in, wired to three other services that were never meant to meet.
Email at a small company today
A suite, per seat
Mailboxes for the humans. Billed per person, whether or not that person reads mail.
Forwarding rules
So hello@ reaches someone. Replies go out from the wrong address and everybody pretends not to notice.
A transactional sender
Because the suite will throttle you, and receipts are not correspondence.
An inbound parser
A second vendor, a second domain, and a webhook that arrives in a shape nobody chose.
Glue
A Zap, a Lambda, a cron. The part that breaks, at the point where none of the four will admit it.
Email on Pidgeon
- One domain
- One account
- Mailboxes people read
- Addresses code owns
- One event stream
- One bill, and it starts at nothing
One account
Four services collapse into one object.
Everything above is the same primitive seen from different sides: an address on a domain you control, with a rule about who answers it. Once that is one object in one system, most of the wiring stops having anything to do.
Addresses, not seats
A mailbox someone reads and an address your code owns are the same object with different answers to "who replies". You are not billed twice for one domain, and you are not billed per human for the ones that are not.
The DNS is done for you
One TXT record proves the domain is yours. MX, SPF, DKIM and DMARC are written for you, correctly, at every registrar we can reach — which is the step that quietly ends most attempts at this.
One log for all of it
Mail arriving, mail sent, a webhook that failed, a message the classifier held: one stream, ninety days, replayable. Not four dashboards and a theory about which one is lying.
Email as infrastructure
Mail arriving is an HTTP request.
Create an address, point it at your endpoint, and the mail that arrives becomes a signed POST in a shape you chose. Nothing to poll, no mailbox to scrape, no IMAP cron job pretending to be an integration.
Read the docsimport { Pidgeon } from '@pidgeon-ai/sdk';
const pidgeon = new Pidgeon({ apiKey: process.env.PIDGEON_API_KEY! });
// `application` means no inbox: mail arriving here
// becomes an event, and there is nothing to read.
const inbox = await pidgeon.identities.create({
domain_id: domain.id,
local_part: 'receipts',
type: 'application',
});
// Somewhere to be told about it. The response carries
// `secret` once — store it, you cannot read it back.
const hook = await pidgeon.webhooks.create({
url: 'https://api.example.com/pidgeon',
event_types: ['message.received'],
});What comes next
Software is about to start writing email.
Most of the mail your company sends in five years will be written by something that is not a person. That works only if the thing writing it has an address of its own, a limit it cannot argue with, and a record of everything it said.
Software gets its own identity
Not your personal address with a script attached. Separate keys, separate limits, separate revocation — so an agent in a loop costs you one address, not a domain reputation.
A person can take the thread
Hybrid addresses let software answer the routine and hand over what it should not touch. The handover is a state on the conversation, not a forwarding rule and a prayer.
Every action is on the record
What arrived, what was sent, under which key, at what time. If an agent is going to write email in your name, the audit trail is not a nice-to-have.
Straight answers
And what it is not
A page that only says what a product does is an advertisement. These are the three things people find out later and are annoyed not to have been told.
It is not end-to-end encrypted
An API that hands your mail to your own code as plaintext cannot also be an API we are unable to read. Encrypted in transit and at rest, and honest about the rest.
It is not a bulk sender
Newsletters and campaigns want a different product with a different reputation model. Sending limits here are sized for correspondence and for software that answers it.
The agent runtime is not built
Addresses an agent answers from exist today; the runtime that answers for it does not. It is on the roadmap and it is not in the product, and we would rather you heard that here.