Choose an email integration for your application
Start with who owns the address and where the conversation record lives. The right receiving model depends on whether your application needs an event, a persistent thread or access to an existing user's mailbox.
| Your application needs to | Start with | Your application retains |
|---|---|---|
| Send a receipt, notification or transactional message | Email API | Business record, sending identity and message outcome |
| Accept email as input to an existing case system | Inbound Email API | Case correlation, job processing and required content copies |
| Give an agent or service a hosted address with readable threads and replies | Agent Mailboxes | Authorized actions, reviewed drafts and reply recovery |
| Read or change a person's existing Gmail or Microsoft mailbox | A connected-account integration | User consent, granted scopes, account lifecycle and provider synchronization |
| Send audience-based campaigns | Email marketing | Audience selection, consent and campaign results |
Send an application message
Use the Email API when the application already knows the recipient and message. Domain setup, templates, scheduling and delivery events belong to the sending journey. A sent message does not require a hosted agent inbox.
If a reply should start work in an existing system, configure inbound receiving. Keep the sending and receiving identities explicit in that system.
Process incoming email in your case system
Inbound email gives your application a received-message identity and access to parsed content. The application owns the case, job queue, correlation and retention of any copies. The inbound versus Mailboxes guide walks through this choice for a booking request with an attachment.
Do not replace a company's existing MX records as a shortcut to application receiving. Follow the receiving guide's dedicated-subdomain or forwarding-address setup.
Give an agent a hosted mailbox
Use Mailboxes when the integration needs its own address and API-readable conversation history. The mailbox groups received and sent messages into threads and exposes a reply operation. Claim an address, then build the Node.js or Python application.
A hosted address does not import an existing user's Gmail inbox, grant access to their Microsoft account or carry out a business action. Your application still owns the customer's authorization and the action behind a reply.
Preserve connected-account requirements
If the application must synchronize an existing user's folders, labels, draft state, calendar or historical mailbox, record those requirements before changing providers. A newly hosted inbox changes the account model.
Nylas has both connected-account products and hosted Agent Accounts. Compare the exact surface being used in the Nylas migration guide. Aurinko migration similarly calls for an explicit account-model decision. Do not describe an OAuth account identifier as a mailbox ID that can be carried over.
Make the decision concrete
Record the address owner, receiving domain, expected reply behavior, conversation owner, needed original content and retention period. Then test one new message, a reply in the existing conversation and a repeated delivery.
Review mailbox retention, current pricing and provider comparisons. Continue through the Mailbox resource library for implementation and migration.
Ressources associées
Poursuivez avec la documentation, les guides et les exemples sur ce sujet. Les ressources sont en anglais.
Regarder le guideGetting started with emailSuivre le parcours d'apprentissageBuild your first integrationGuide d'implémentationSend your first email
Essayez la pratique et obtenez un guide d'implémentation