Email is still where a large share of business actually happens, and software products have learned to tap into it rather than compete with it. The building block behind that trend is the email API: a programmable way for an application, with the user's permission, to read, send, and organize messages inside that user's real mailbox. If you want to see how this works across Gmail, Outlook and IMAP, this email API overview lays out the fundamentals. This piece takes the product angle instead: five features users now expect, and the specific technical ingredients each one demands.
A quick clarification first. This category is not about the systems that send receipts or newsletters from a company's own domain. Everything below happens inside an individual user's Gmail, Outlook, or other mailbox, on that user's behalf, after they have connected their account.
A complete conversation history inside the CRM
What users see: open a client record and every email exchanged with that person is there, without anyone forwarding or copying anything.
What it takes: an initial backfill that imports past messages when the account is connected, then continuous sync so new ones appear. Messages must be matched to records, usually by comparing sender and recipient addresses with the CRM's contacts and company domains. Privacy settings matter here, because not every email a salesperson receives belongs in a shared system. Good implementations let users exclude personal threads or certain domains, and store only what the feature needs. Read access to the mailbox is required, which in the case of Gmail means requesting a scope that Google classifies as restricted and subjects to a security review.
Sending as the user, inside the existing thread
What users see: they write a message from inside the app and it leaves from their own address, lands in the recipient's inbox as a normal email, and appears in their own Sent folder.
What it takes: sending through the user's provider rather than through a third-party relay, so the message carries the user's identity and reputation. Threading is the subtle part. For a reply to stay in the same conversation, the app has to set the right reply headers and reference the original message, and the copy in the Sent folder must look like the user wrote it in their usual client. Attachments, signatures, and HTML formatting all have to survive the round trip. Products that get this wrong produce duplicated threads and confused recipients, which users notice immediately.
Knowing the moment someone replies
What users see: an outreach sequence stops automatically when a prospect answers, a recruiter gets an alert when a candidate responds, a deal status changes because the client wrote back.
What it takes: real-time notifications. Polling every mailbox every few minutes is slow and wasteful, so providers offer push mechanisms: Gmail publishes changes through Google's Pub/Sub service, Microsoft Graph uses webhook subscriptions that must be renewed regularly, and generic IMAP servers rely on a long-lived connection using the IDLE command. The app then has to decide whether an incoming message is actually a reply to something it sent, by examining thread references, and it should also detect automatic out-of-office answers so that a vacation notice does not count as engagement.
Team inboxes and lightweight helpdesks
What users see: a shared address like support@ or hello@ becomes a queue inside the product, with assignments, statuses, and internal notes, while customers simply see normal email.
What it takes: syncing one mailbox for many users, which raises questions of permissions and auditability. The app needs to track status changes made in the product and, ideally, reflect some of them back in the mailbox (read, archived, moved). Folder and label handling differs by provider, so a "closed" state might map to a label in Gmail and to a folder elsewhere. Reliable deduplication is essential, because the same message can surface through several paths and a support agent answering twice is worse than not answering at all.
AI agents that read, sort, and draft
What users see: an assistant that labels incoming messages by urgency, summarizes long threads, extracts an invoice amount or a meeting request, and prepares a draft reply for a human to approve.
What it takes: clean, structured message data. Language models work far better with decoded text, separated quoted history, and attachment content than with raw email source. The agent also needs safe write actions: applying a label, creating a draft rather than sending directly, moving a message. Scope matters again, since an agent that can send freely carries more risk than one that only drafts. Many teams keep a human approval step for anything that leaves the mailbox, and log every action the agent takes so users can see what happened and undo it.
The shared foundation under all five
Line these features up and the same requirements appear every time:
- Secure account connection through OAuth, with clean handling of expired or revoked access.
- Support for several providers, because customers do not all use the same email service.
- Initial backfill plus incremental sync, without duplicates or gaps.
- Real-time events, regardless of whether the provider uses Pub/Sub, webhooks, or IDLE.
- Sending and threading that look native in the user's own client.
- Compliance evidence that enterprise buyers will ask for, such as SOC 2 Type II and GDPR, plus Google's CASA assessment when Gmail restricted scopes are involved.
A software team can build this foundation itself against each provider, which makes sense when email is the core of the product. Many teams instead use a unified email API that exposes Gmail, Outlook, and IMAP behind one interface. Unipile is one such option, alongside providers like Nylas and Aurinko: it connects users' own accounts, acts on their behalf, is SOC 2 Type II certified, and charges per connected account. Either way, the lesson for anyone planning these features is the same. The visible feature is the small part. The plumbing underneath, connection, sync, events, and trust, is what decides whether users rely on it every day or quietly turn it off.
