# Email API vs inbox API: What are you actually building? > Learn the difference between a sending API, inbound email processing, and an inbox API, then choose the right email architecture for your product. An email API sends or receives email for software. An inbox API gives software access to a stored mailbox and its conversations. The terms overlap, and "inbox API" is not a formal industry standard. The useful question is simpler: does your application need to move messages, or does it need to own and revisit a mailbox? Choose a sending API for receipts, login links, alerts, and other messages triggered by your product. Choose an inbox API when your application or agent must receive mail, keep threads, read old messages, and reply from a durable address. ## Three services often called an email API "Email API" can describe three different products. ### 1. A sending API A sending API accepts a request from your application and delivers an email. Your code supplies the sender, recipients, subject, and body. This is the common choice for: - Email verification - Password resets - Receipts - Account alerts - Export notifications - Booking confirmations The provider may track delivery, bounces, and complaints. It may also offer templates, analytics, and suppression lists. A sending API does not necessarily provide a mailbox. A recipient may reply, but your application needs somewhere to receive and process that reply. ### 2. An inbound email parser An inbound parser accepts email for an address or domain, turns the message into structured data, and sends it to your webhook. Postmark, for example, describes its inbound service as accepting and parsing a message, then posting it to a configured URL as JSON. Resend can notify an application with an `email.received` webhook, after which the application can retrieve the message and its attachments. Both products now cover more than one category. See [Startup Mail vs Postmark](https://staging.startupmail.dev/compare/postmark-alternative.md) and [Startup Mail vs Resend](https://staging.startupmail.dev/compare/resend-alternative.md) for their current receiving and storage models. This removes much of the MIME parsing work. It still leaves important decisions to your application: - Where will the message remain after the webhook? - How will messages become conversations? - What happens when the webhook is delivered twice? - Who can read the message? - How will a person inspect or reply to it? - How will you search old conversations? An inbound webhook is an event. It is not, by itself, a complete inbox. For a closer look at this boundary, read [inbound email webhook vs persistent mailbox](https://staging.startupmail.dev/guides/inbound-email-webhook-vs-persistent-mailbox.md). ### 3. An inbox API An inbox API treats the mailbox as a lasting resource. It stores incoming and outgoing messages, groups replies into threads, and lets an authorized client return later to read the current state. It may also provide a human inbox, webhooks, forwarding, search, attachments, and mailbox permissions. This is the model Startup Mail uses. The mailbox is the source of truth. A webhook tells your application that something changed, while the API returns the current conversation. ## The practical difference | Question | Sending API | Inbound parser | Inbox API | | -------------------------------------- | ------------------------------------------ | --------------------------------------- | ------------------------------------------------ | | Can it send email? | Usually | Sometimes | Usually | | Can it receive email? | Not always | Yes | Yes | | Does it store a mailbox? | Usually no | Varies | Yes | | Does it preserve threads? | Delivery history only or provider-specific | Your application may need to build this | Yes | | Can a human read the same mailbox? | Usually no | Not without another interface | Often | | Does software fetch old conversations? | Usually limited to delivery records | Varies | Yes | | Does it notify code about new mail? | Delivery webhooks | Inbound webhook | Inbound webhook plus mailbox API | | Main job | Deliver a message | Turn incoming email into data | Maintain an email identity and its conversations | Provider names alone do not settle this table. Products change, and some now span more than one category. Read the current documentation and test the exact message lifecycle you need. ## Persistence is the dividing line Suppose a new message reaches your application while its webhook endpoint is unavailable. With a basic parser, the provider may retry delivery. Your application is still responsible for storing the message once it arrives. If processing succeeds but the acknowledgement fails, the event may arrive again. You need a stable event ID and idempotent processing so the second delivery does not create a duplicate action. With an inbox API, the webhook can remain a notification. Your worker verifies the event, records its delivery ID, and fetches the thread from the API. If the webhook repeats, the mailbox still has one conversation. This does not remove the need for careful code. It gives that code a durable object to read. Startup Mail signs webhook requests and retries failed deliveries. Its documentation recommends acknowledging the webhook quickly, deduplicating by delivery ID, and fetching the current thread after the event. ## Threads matter when the conversation continues A message is one email. A thread is the conversation that links messages and replies. Threads become important when: - A customer replies to a receipt. - A vendor sends several messages about one order. - A support request moves between a person and an agent. - An automated process pauses for an answer. - A human reviews an agent's draft before it is sent. A sending API can put reply headers on an outgoing message. An inbound parser can expose the headers on the response. Your application may still need to match them, store the messages, handle missing or malformed headers, and present the conversation. An inbox API should make the thread a first-class resource. In Startup Mail, an application can list threads, retrieve every message in a thread, and reply to a specific message so the outgoing email stays in the conversation. ## The access model matters as much as the message model Email contains private and often sensitive data. A useful API must answer more than "does this key work?" Ask: - Which mailboxes can the identity see? - Can it read without sending? - Can it send without changing workspace settings? - Does an administrator automatically gain access to private messages? - Can one compromised key expose every mailbox? - Can access expire or be revoked? - Are attachments checked against the same mailbox permissions? Startup Mail separates human workspace roles from API resource boundaries. A key can cover the organization, one tenant, or one mailbox. Capabilities then control what it can do inside that boundary. An agent can start with a mailbox-scoped read-only key and receive draft or sending permission only when the workflow needs it. The Gmail API uses a different model. Applications request access to a user's Gmail account through Google authorization. It is a strong fit when the mailbox already belongs to a Gmail user. Startup Mail is a more direct fit when the application needs a mailbox created for the workload itself. ## Which type should you choose? Choose a sending API if: - Your application sends messages but does not need a human inbox. - Replies are rare or can go to an existing support address. - Delivery analytics and high-volume sending matter more than stored conversations. - Your main tasks are receipts, alerts, login links, or notifications. Choose an inbound parser if: - Incoming email is only an input to another system. - You already have a database and conversation model. - Your engineers want control over storage, threading, permissions, and display. - You can operate retries, MIME handling, attachments, and failure recovery. Choose an inbox API if: - The address must keep a readable history. - Software needs to return to old conversations. - People and software need access to the same mail. - Replies must stay attached to the right thread. - You need mailbox-level permissions rather than one broad domain route. - An agent needs a stable email identity. ## Can you combine them? Yes. A split system is often sensible. A product can use a specialist sending API for large volumes of application notifications and use an inbox API for `support@`, `vendors@`, or an agent address that receives replies. The main risk is fragmentation. Decide which system owns each address, message type, and reply path. Do not let two systems believe they are the source of truth for one mailbox. A simple boundary might be: - Sending API: automated messages that do not start an ongoing conversation. - Inbox API: direct conversations and messages where a reply matters. - Marketing platform: newsletters and campaigns with consent and unsubscribe management. Startup Mail is built for the second group and for requested transactional mail. It is not a marketing campaign service. ## Questions to ask before choosing 1. Must the address receive replies? 2. Must messages remain available after processing? 3. Do people need a web inbox? 4. Does the application need threads or only individual events? 5. Who may read and send from each address? 6. How will duplicate webhook deliveries be handled? 7. How will attachments be stored and treated as untrusted input? 8. Do you need OAuth access to a person's mailbox or a key for a workload mailbox? 9. Will the service send campaigns, direct conversations, or requested transactional mail? 10. Which system owns the canonical copy of a message? The right API follows from those answers. Start with the message lifecycle, not the vendor list. If your decision is mainly about employee mail versus product notifications, continue with [transactional email service vs business email hosting](https://staging.startupmail.dev/guides/transactional-email-vs-business-email.md). ## Sources - [Postmark inbound webhook documentation](https://postmarkapp.com/developer/webhooks/inbound-webhook) - [Postmark inbound processing guide](https://postmarkapp.com/developer/user-guide/inbound) - [Resend receiving email documentation](https://resend.com/docs/dashboard/receiving/introduction) - [Google Gmail API overview](https://developers.google.com/workspace/gmail/api/guides) - [How Startup Mail works](https://staging.startupmail.dev/docs/how-it-works.md) - [Startup Mail API overview](https://staging.startupmail.dev/docs/api-overview.md) - [Startup Mail receiving guide](https://staging.startupmail.dev/docs/receiving.md) - [Startup Mail webhook guide](https://staging.startupmail.dev/docs/webhooks.md) - [Startup Mail mailbox guide](https://staging.startupmail.dev/docs/mailboxes.md) ## Related reading - [Startup Mail vs Postmark](https://staging.startupmail.dev/compare/postmark-alternative.md): Compare Startup Mail and Postmark for transactional sending, inbound email, persistent inboxes, teams, APIs, analytics, and pricing. - [Startup Mail vs Resend](https://staging.startupmail.dev/compare/resend-alternative.md): Compare Startup Mail and Resend for custom-domain email, inbound mail, APIs, MCP, human inboxes, transactional sending, and pricing. - [Inbound email webhook vs persistent mailbox: which do you need?](https://staging.startupmail.dev/guides/inbound-email-webhook-vs-persistent-mailbox.md): Compare inbound email webhooks with persistent mailboxes, including storage, threads, retries, human access, and the cases where you need both.