CRM platforms live or die by the quality of their communication data. When meetings, email, and notes don’t flow into the record automatically, reps stop trusting it, managers lose pipeline visibility, and the whole system decays into a stale list of names. The Nylas APIs give you direct access to your users’ email, calendar, contacts, and meeting data across every major provider through one schema, so you can build that sync layer without writing a separate integration for Google, Microsoft 365, and everything else.
The recipes below split into two flavors: traditional integration that syncs, logs, and exports, and AI-agent workflows that triage, draft, and score relationships. Each one names the products to combine for the job and links a full walkthrough, so the fastest path is to pick the workflow you need, skim the constraints that bite (provider differences, token lifecycle, and pagination), then follow the recipe for the step-by-step build.
Logging email and calendar activity into a CRM
Section titled “Logging email and calendar activity into a CRM”The foundation of any CRM integration is activity capture: every sent message, received reply, and booked meeting attached to the right contact or deal. You read messages from GET /v3/grants/{grant_id}/messages and events from GET|POST /v3/grants/{grant_id}/events, then map each one onto a CRM object by matching participant email addresses. One grant covers all six supported email providers (Google, Microsoft 365, Yahoo, iCloud, IMAP, and Exchange through EWS) with a single unified schema, so your mapping code never branches on provider.
The decision here is mostly about volume and direction. Pulling history in bulk uses the same list endpoint, paginated at 50 messages per page by default and up to 200 per page through the limit parameter, with a page_token cursor to walk the remaining records. Writing activity back, such as sending a follow-up from inside the CRM, uses the messages and threads endpoints. The “Build with Nylas” recipes below cover the full export logic for the three CRMs developers ask about most.
Think about identity resolution early, because it shapes everything downstream. A single deal can touch a dozen people across forwarded threads, and the same person often sends mail from two addresses. Read GET /v3/grants/{grant_id}/threads to group a conversation as the provider sees it, then resolve participants against your CRM’s contact records before you create activity. Getting this wrong produces duplicate timeline entries, which is the fastest way to lose rep trust in the data. Decide whether the mailbox owner, the deal, or the account is the anchor object in your model, and map every message and event onto that anchor consistently.
The two tables on this page index every CRM tutorial. Start with the table that matches your job: direct integration, or agent-driven intelligence.
Build with Nylas
Section titled “Build with Nylas”Patterns for keeping a CRM accurate and current using the API directly.
| Tutorial | Products | What you’ll build |
|---|---|---|
| Sync calendar events to a CRM | Calendar, Webhooks | A pipeline that mirrors calendar events into CRM records in real time |
| Automatically log meeting notes to your CRM | Notetaker, Webhooks | A system that automatically pushes meeting transcripts and summaries into CRM entries |
| Sync email contacts to a CRM | Email, Contacts | Pull new senders from team mailboxes, enrich with signatures, push to your CRM on a schedule |
| Export email data to Salesforce | Map senders to Salesforce Contact / Account / Task. Composite + Bulk API 2.0 patterns | |
| Export email data to HubSpot | Lean on HubSpot’s automatic company creation; batch contacts and engagements | |
| Export email data to Pipedrive | Map senders onto Pipedrive’s Organization → Person → Deal hierarchy | |
| Automate a sales pipeline | Email, Calendar, Contacts | A pipeline that tracks prospect communication, schedules meetings, and logs activity across email and calendar |
Syncing contacts and enriching records
Section titled “Syncing contacts and enriching records”A CRM is only as useful as its contact records, and those records go stale fast. The contacts endpoints, GET|POST /v3/grants/{grant_id}/contacts, let you read a user’s address book and write enriched records back, while GET /v3/grants/{grant_id}/contacts/groups exposes the provider’s groups so you can preserve segmentation. The same unified schema covers all 6 providers, so a contact from a Microsoft 365 account looks identical to one from Google in your code.
The pattern most teams want is sender discovery: watch team mailboxes for new external addresses, pull the matching contact, and create the CRM record before a rep has to type anything. Pair the contacts read with the messages list so you catch people who email in but never appear in the address book. For richer records, parse email signatures for titles, phone numbers, and social links, then write the result back through POST /v3/grants/{grant_id}/contacts. The signature-enrichment agent recipe below cross-references those signals across several messages to raise extraction accuracy before it updates a record.
Below is the shortest possible read against the contacts endpoint. It lists contacts for a grant so you can confirm the address book is reachable before you build the sync loop, and it returns the same JSON shape across every provider.
curl --compressed --request GET \ --url 'https://api.us.nylas.com/v3/grants/<NYLAS_GRANT_ID>/contacts' \ --header 'Accept: application/json' \ --header 'Authorization: Bearer <NYLAS_API_KEY>' \ --header 'Content-Type: application/json'Nylas for AI Agents
Section titled “Nylas for AI Agents”AI-driven CRM workflows: relationship intelligence, contact enrichment, and inbox triage.
| Tutorial | Products | What you’ll build |
|---|---|---|
| Map communication patterns between orgs | Email, Calendar | Score every external contact 0–100 across four signals; surface single-threaded accounts at churn risk |
| Parse signatures for contact enrichment | Email, Contacts | Extract titles, phone numbers, and LinkedIn URLs from inbound mail; cross-reference across messages for accuracy |
| Build an AI email triage agent | cron-driven triage that classifies prospect mail and drafts replies for the highest-priority items | |
| Multi-turn email conversations | Agent Accounts, Email | Send-receive-respond loops with persistent state spanning the full sales cycle |
Capturing meeting notes automatically
Section titled “Capturing meeting notes automatically”Meeting notes are the highest-value, lowest-compliance data in any CRM, because reps rarely type them up. Notetaker closes that gap: POST /v3/grants/{grant_id}/notetakers sends a bot into a Zoom, Google Meet, or Microsoft Teams call, and after the meeting ends, GET /v3/grants/{grant_id}/notetakers/{notetaker_id}/media returns the recording and transcript URLs. You then attach the summary to the deal automatically, so the activity log fills itself.
The architecture choice is when to fire the invite. Grant-scoped Notetaker ties the recording to a connected calendar account, which is the right call when notes belong to a specific rep’s deals. A standalone POST /v3/notetakers works when you only have a meeting link and no grant. Because the media endpoint only returns assets after the meeting wraps, pair Notetaker with a webhook so your CRM ingests the transcript the moment it’s ready instead of polling. The automatic logging recipe in the first table walks through that exact pipeline.
There’s also a decision about how much of the transcript belongs in the CRM. Most teams don’t want a raw word-for-word dump cluttering the deal record. A common approach is to store the summary and action items on the timeline and keep the full transcript URL as a link for reps who want to dig in. Sending the bot from the terminal with nylas notetaker create --meeting-link <url> during testing lets you see exactly what the media endpoint returns before you decide what to persist.
The product picture matters when you scope this feature. Meeting capture only makes sense for users on a calendar-backed account, and while the unified schema covers six email providers (Google, Microsoft 365, Yahoo, iCloud, IMAP, and Exchange through EWS), standard IMAP grants carry no calendar. A notes workflow that assumes every connected account can host meetings will quietly skip those users, so check the grant before you surface the feature in your CRM’s interface. Authentication runs in the background regardless of provider, because access tokens expire after 3,600 seconds and the platform refreshes them for you, so a long recording job never stalls on an expired credential partway through a call. That lets you treat the bot as fire-and-forget: invite it, wait for the webhook, and pull the media when it lands.
Keeping the CRM current in real time with webhooks
Section titled “Keeping the CRM current in real time with webhooks”Polling a mailbox on a timer means stale records and wasted API calls. Webhooks flip that: the API pushes an event the instant a message arrives, an event changes, or a Notetaker transcript finishes, so the CRM updates within seconds instead of on the next cron tick. You register a webhook against /v3/webhooks with the triggers you care about, and for high-volume tenants you can fan delivery through a Pub/Sub channel at /v3/channels/pubsub.
Webhooks and bulk reads do different jobs, and the right design uses both. The list endpoints return 50 messages per page by default and up to 200 with the limit parameter, which is how you backfill a tenant’s history when they first connect an account. After that initial load, pushed events keep the record current without you ever paging again. Because the same six providers sit behind one schema, a single webhook handler processes Google and Microsoft 365 traffic identically, so you write the ingestion path once instead of per provider. The split to remember is simple: paginate once to catch up, then let real-time triggers carry every change going forward.
The decision is which triggers to subscribe to, and you should subscribe narrowly. A CRM sync typically needs message-created and event-updated triggers, plus the Notetaker media trigger for the notes pipeline above. Subscribing to triggers you don’t process just adds load and noise to your endpoint. Creating a webhook from the CLI takes one line, which makes it easy to wire up a tunnel during local development before you point it at production. Plan for delivery reliability too, since your handler must be idempotent: the same event can arrive more than once, and a CRM that creates a new activity on every delivery ends up with duplicates. Key your writes on the message or event ID so a repeated webhook updates the existing record instead of cloning it.
# Register a webhook for real-time CRM syncnylas webhook create --url https://crm.example.com/nylas/events --triggers message.created,event.updated
# See every trigger you can subscribe tonylas webhook triggersRun nylas webhook list to confirm registration and nylas webhook test send <url> to fire a sample payload at your endpoint. Combining real-time webhooks with the bulk list endpoints gives you the standard pattern: backfill history once with pagination, then stay current with pushed events.
Managing CRM activity from the terminal with the Nylas CLI
Section titled “Managing CRM activity from the terminal with the Nylas CLI”The CLI is the fastest way to validate a CRM integration before you write a line of application code, and it covers the same surface as the API. It mirrors the API across email, calendar, contacts, Notetaker, and webhooks, so each workflow above has a one-line equivalent you can run against any of the 6 providers. Authenticate once with nylas init --api-key <key>, then nylas auth whoami confirms which grant you’re acting as.
These commands map directly onto the products on this page. Use them to inspect a mailbox, list upcoming meetings, check the contact book, and send a Notetaker bot into a live call, all without leaving the terminal.
# Inspect email activity for a grantnylas email listnylas email threads list
# Review and create calendar activitynylas calendar events listnylas calendar events create --title "Discovery call" --start <ts> --end <ts>
# Sync and create contactsnylas contacts listnylas contacts syncnylas contacts groups list
# Capture meeting notesnylas notetaker create --meeting-link https://meet.google.com/abc-defg-hijnylas notetaker media <id>Add the global --json flag to any command to get machine-readable output you can pipe into a sync script. The full command reference lives at cli.nylas.com/docs/commands.
Things to know about CRM integrations
Section titled “Things to know about CRM integrations”CRM integrations break in predictable ways, and most of the failure modes come from provider differences and token lifecycle rather than your business logic. The biggest one is cross-provider sync. With six email providers behind one schema, your sync code stays uniform, but the underlying accounts don’t behave identically: IMAP grants carry no calendar at all, so any calendar feature silently does nothing for those users. Detect the provider on the grant and degrade gracefully instead of assuming every account has events.
Token refresh is the second trap. OAuth access tokens expire after 3,600 seconds, and the platform refreshes them automatically, so you should never cache a token for longer than its lifetime or build your own refresh loop. Treat the grant as the durable identity and let the API hand you a fresh token each call. Pagination is the third. The messages and contacts list endpoints return 50 records per page by default and up to 200 with the limit parameter, and you must follow the page_token cursor to the end. A backfill that stops after one page is the most common reason a CRM looks half-synced.
Attachment handling has a provider quirk worth planning for: attachments up to 25 MB are inlined in the message response, while Microsoft grants support files up to 150 MB through upload sessions. If your CRM stores email attachments as deal artifacts, size-check before you assume the bytes are inline. Notetaker has its own timing rule, since the media endpoint only returns the recording and transcript after the meeting ends, so a CRM that expects notes mid-call will get nothing. Wire the media fetch to a webhook trigger rather than polling. Across all of these, the safe default is to assume providers differ, read the grant’s capabilities, and let real-time webhooks (not timers) drive freshness.
What’s next
Section titled “What’s next”- Email API overview: read, send, and manage email
- Calendar API overview: manage calendars, events, and availability
- Notetaker API overview: meeting recording and transcription
- Webhook best practices: reliable real-time event processing
- Nylas CLI command reference: every command for email, calendar, contacts, Notetaker, and webhooks