Inbound email → Notion
ingestlayer mints a unique, opaque inbound address for the source. Forward the mail you want ingested to it, and every message is parsed into an event — sender, subject, body, and attachment metadata.
01source
02pipeline · 3 steps
- 01ENRclassifyintent → sales | support | spam
- 02ENRsummarizelong thread → one line
- 03MUTredact.piimask PII before posting
03destinations · 1
- tonotion.dbNotiondatabaseSignups
how events arrive
- 01
mint an inbound address
Add an inbound-email source; ingestlayer generates a unique, opaque address (an in_… local-part) on its inbound domain. Nobody else can claim it, and there's no DNS or MX record to configure.
- 02
forward your mail to it
Send or forward the messages you want ingested to that address — a forwarding rule, an alias, or a BCC. Only addresses you mint here accept inbound; everything else arriving at the domain is dropped.
- 03
optionally restrict senders
Set a from-domain allowlist so only mail from domains you trust becomes an event; everything else is dropped at the edge before it reaches a pipeline.
{
"type": "email.received",
"from": "ada@acme.com",
"to": "in_7g3k9d2a@inbound.ingestlayer.com",
"subject": "Demo request — Acme",
"text": "Hi, we'd love a demo for a team of 40…",
"attachments": [
{ "filename": "brief.pdf", "content_type": "application/pdf" }
],
"body_status": "fetched"
}route it to Notion
Append events as rows to a Notion database, or content to a page. Connect once with OAuth, pick the target per pipeline.
- 01
connect your workspace
Authorize the ingestlayer Notion integration over OAuth from the destinations page, then choose which databases and pages it may touch. We hold only that workspace's access token, in-region, in the same KMS as your other credentials.
- 02
pick a target
Per pipeline, choose a database to append a typed row to, or a page to append content to. The picker lists exactly what you shared with the integration during authorization — nothing else.
- 03
map the columns
For a database, match event fields to Notion properties — automatically by column name, or per-column with $event.* templates. The title column falls back to the event name, so a row is never blank. For a page, the rendered body is appended as blocks.
┌─ Signups · database ───────────────────┐ │ Name ada@acme.com │ │ Plan ● pro │ │ Source marketing-site │ │ Signed up 2026-06-03 │ └─────────────────────────────────────────┘
notes
- Notion grants access page by page: the integration only sees databases and pages you explicitly share during authorization. Add the target there, or the delivery dead-letters as object_not_found.
- Each column is coerced to its Notion type — number, date, select, checkbox, URL, and so on. Properties an integration can't write (people, relations, files, formulas, rollups) are skipped rather than guessed.
- Title and rich-text values cap at 2000 characters per block and are chunked beyond that; a single page append tops out at 100 blocks.
- Tokens don't expire, but revoking the integration inside Notion flips the destination to an error state — reconnect from the destinations page to resume delivery.
questions
- Do I have to change my DNS or MX records?
- No. ingestlayer generates the inbound address — you just forward mail to it. There's no MX record, domain verification, or DNS change to set up.
- How are attachments handled?
- The event includes each attachment's filename and content type so you can branch on them, but the bytes aren't routed — keeping large files out of your chat and your warehouse.
- Can it triage email before it reaches a channel?
- Yes — classify labels the intent (sales, support, spam) and summarize collapses a long thread to a line, so the channel sees a clean, sorted signal instead of a raw forward.
Inbound email, routed elsewhere
- Inbound email → SlackSlack
- Inbound email → DiscordDiscord
- Inbound email → TelegramTelegram
- Inbound email → EmailEmail
- Inbound email → WebhookWebhook
- Inbound email → PostgresPostgres