Use an Email Service Payload when the inbound message is an email rather than an HTTP request.

This is useful for systems that can send emails but cannot call an API, or for operational inboxes where email is still the source event. Payloads receives the email, models the email content, and maps values into Salesforce records.

If the source system can call an HTTP endpoint, Configure an API Push Into Salesforce Payload may be a cleaner fit.

Use an Email Service Payload when you need to:

The Stripe demo Email Service Payload represents a billing notification inbox. Payloads can receive a billing email and map values from that email into Salesforce.

An Email Service Payload starts with Incoming Email.

The Incoming Email section contains Email Contents and Data Targets. Email Contents model the values available from the inbound email. Data Targets map those values into Salesforce records.

The Email Services section defines the email service records and addresses associated with the Payload.

The Email Service layout replaces HTTP request setup with Incoming Email and Email Services sections.

Start with the main fields on the Payload record.

Email Service Payloads do not need an external API endpoint, HTTP method, or outbound callout configuration. The runtime starts when Salesforce receives an email for the configured service address.

Email Contents describe the values Payloads can read from the inbound email.

Typical values include:

Model the parts of the email that the Salesforce mapping needs. If the source email body is structured, keep the mapping focused on stable values rather than visual formatting.

Data Targets decide what Salesforce records Payloads creates or updates from the email.

Each target should have a clear object, operation, identifier, and field mappings. For example, an email could create a Case, update an Opportunity, or create a custom log record linked to an Account.

Be careful with identifiers. Email addresses and subjects are not always unique. If the email includes a reliable external reference, use that where possible.

The demo maps stable email values into a follow-up Task, keeping the inbound email handling visible on the Payload.

The Email Services section links the Payload to the inbound email address Salesforce will use.

Create an Email Service record for each mailbox-style route you want Payloads to handle. Keep the name and API name clear enough that an admin can understand which external process sends mail to that address.

If the same source system sends materially different email formats, consider separate Payloads and service addresses. That keeps the Email Contents and Data Targets easier to maintain.

Test with a representative email from the source system.

Use an email that includes the same subject format, sender address, body structure, and attachments that production messages will use. A manually typed email is usually not a good test if the real source system sends a structured notification.

After the test email is processed, open the Job record and review the inbound email values, target mappings, and created or updated Salesforce records.

Before you test the Payload, check that:

If the Job does not look right, start with the inbound email content on the Job. It shows what Payloads received before any mapping logic ran.