GET /api/v1/receiving/emailsFind the recent messages attributed to the active project.
Email receiving API for inbound workflows.
Verify a receiving subdomain and turn every message into a signed email.received event. Fetch the body or an attachment only when the workflow needs it.
- Signed webhooks
- Fetch on demand
- Paid plans
Webhook firstBodies on demandOne signature pathProject attributed
Metadata first
The webhook is small on purpose.
Route the message from the event: sender, recipients, subject, receiving address, and attachment metadata. The full MIME body stays out of your handler until your workflow asks for it.
Read the webhook guideSigned with
x-noticeapi-*Attachment metadata, not file bytesemail.received
{
"type": "email.received",
"emailId": "rx_0f83...",
"messageId": "<message@example.com>",
"from": "sender@example.com",
"to": ["reply@example.com"],
"subject": "Re: Invoice",
"receivedFor": ["support@reply.example.com"],
"receivedAt": "2026-07-03T18:04:14.000Z",
"attachments": [
{ "id": "att_123", "filename": "invoice.pdf", "contentType": "application/pdf", "size": 48213 }
],
"accountId": "..."
}Mailbox-shaped input
API-shaped output.
NoticeAPI takes the message off the wire, parses it, stores it, and hands your app a clean event it can route.
- CaptureMX receives the message
Point a verified receiving subdomain at NoticeAPI and accept mail for any address on it.
- ParseMIME becomes structured data
Headers, text, HTML, envelope recipients, and attachment metadata are parsed and stored.
- Emitemail.received is signed
A small metadata-first event reaches your webhook as soon as the message lands.
- FetchYour app pulls what it needs
Bodies, headers, and raw attachment bytes stay one authenticated request away.
Fetch on demand
Pull the details only when the workflow needs them.
Use a scoped key to retrieve the stored message, list its attachments, or download one file. Every resource stays attributed to the project that owns the receiving domain.
GET received email
curl https://www.noticeapi.com/api/v1/receiving/emails/rx_0f83... \ -H "Authorization: Bearer ntc_xxxxxxxxxxxxxxxxxxxx"
ResourceUse it when
GET /api/v1/receiving/emails/:idRead headers, HTML, text, envelope recipients, and attachment metadata.
GET /api/v1/receiving/emails/:id/attachmentsInspect ids, filenames, content types, and sizes before downloading.
GET /api/v1/receiving/emails/:id/attachments/:attachmentIdRetrieve the raw bytes with the stored MIME content type.
Verified receiving domains
Give every inbound workflow its own address space.
Add a dedicated subdomain such as reply.example.com, publish the ownership TXT and MX records, then verify DNS. Any address on that domain can become a route into your application.
- Domains are owned by one project
- Sending and receiving status stay independent
- Existing mailbox MX can remain untouched
reply.example.comVerified
OwnershipTXT recordVerified
Inbound routeMX recordVerified
Keep normal mail where it is.Use a dedicated subdomain so your existing mailbox MX records stay untouched.
Built for app workflows
Inbound email without an inbox somebody has to watch.
This is API-based receiving for software workflows. Use a mailbox provider when people need IMAP, POP3, webmail, or a shared inbox.
Reply handling
Route replies back to the record, conversation, or workflow that created the original message.
Ticket intake
Turn support@ or help@ into structured requests your application can triage.
Form responses
Receive a customer response without polling a mailbox or maintaining an SMTP server.
Document ingestion
Inspect attachment metadata, then download only the files your workflow intends to keep.
Ready to receive?
Turn the next reply into an app event.
Start with a verified receiving subdomain, connect one signed webhook, and fetch only what the workflow needs.