Skip to main content
Receiving email through the organization’s own Resend account, by pointing the Resend webhook at an automation. It’s opt-in: with no automation configured, nothing happens. It shares the same ingestion core as the native Inbound Email path — only the entry door changes.

​
Two paths, one core

Email ingestion has two entry points.
  • Native: the organization uses the {slug}@inbound.dilli.studio address. The platform receives the email and processes it. No provider account required. See Inbound Email.
  • Your own Resend: the organization points the Resend webhook at an automation. The email content is fetched with the organization’s own key and follows the same processing.
Both paths share sender matching, enrichment, contact creation, and activity logging. Behavior from entry onward is identical. This page covers the second path.

​
How to configure

The connection is made through an automation, not a dedicated settings screen.
  1. Create an automation with a Webhook trigger. It exposes an inbound URL.
  2. Add the receive_resend_email node to the automation. It parses the Resend payload and calls the ingestion core.
  3. In the Resend dashboard, configure the received-email webhook to point at the automation URL.
  4. Make sure the organization’s Resend API key is configured — the node uses it to fetch the full email content.
From then on, each email Resend receives fires the webhook, the node fetches the content, and ingestion happens.

​
How the sender is identified

Sender resolution is the same across both paths:
  1. By contact identity (email): if the sender address is already linked to a contact as an identity, the email lands on that contact.
  2. By contact email field: with no matching identity, the system looks up the email on the contact record.
  3. Auto-creation: with no contact found and the toggle on, a new contact is created with source email_inbound.
When the contact exists but is missing a name or email, those fields are filled from the received email.

​
Logging and idempotency

Each processed email becomes an activity of type email on the contact and its related deals. Ingestion is idempotent. Each email is logged once, identified by the combination of organization, provider, and the provider’s email ID. The same email redelivered by the webhook does not create a duplicate activity — relevant because webhooks redeliver.

​
Fields

​
Automation node (required)

The receive_resend_email node, inside an automation with a Webhook trigger. Without it, the Resend payload arrives but is not ingested.

​
Resend API key (required)

The organization’s own key. The node uses it to fetch the full email content from Resend. Without a valid key, content is not retrieved.

​
Auto-create contact (default: off)

When on, email from an unknown sender creates a new contact with source email_inbound. Applies to both entry paths.

​
Automation events

Ingestion emits two events, regardless of path:
  • email.received — whenever an email is ingested successfully.
  • email.contact.auto_created — when ingestion creates a new contact.

​
Native or your own Resend: which to use

Use native when the organization has no email account of its own or doesn’t want to keep one. It’s the lowest-configuration path: the address already exists. Use your own Resend when the organization already runs a Resend account, wants its own domain on the sender, or has routing rules that should run before the CRM receives. Control of the account and keys stays with the organization.

​
Compatibility

If you don’t configure the automation, nothing changes. The native path doesn’t depend on it, and organizations without a Resend account keep using the inbound address normally. Auto-contact creation starts off.

​
Scope limits

Not sending. This path covers only inbound email — outbound and campaigns via Resend are not part of it. Not a mailbox. Content becomes activity and history, not an inbox inside Dilli. Doesn’t manage the Resend account. The platform consumes the webhook and uses the key to read content; all account administration stays in Resend, with the organization.