CRM API Integration: Real-Time Customer Data Across Sales Pipelines

February 7, 2026

A CRM API integration lets your application read and write customer-relationship data — contacts, companies, deals, pipelines, leads, and activities — from CRM platforms like Salesforce, HubSpot, Pipedrive, Microsoft Dynamics, and 45+ others. The architectural decision that separates a useful CRM integration from a brittle one isn't which CRM to support first. It's whether your application reads live data directly from the source CRM on every request, or works against a synchronized cache that's bounded by sync interval. The choice determines whether your sales-context features, AI integrations, and pipeline analytics reflect what's happening right now — or what was true at the last sync.

This guide covers how CRM APIs work, the canonical objects across CRM platforms, where vendor variability shows up in practice, and how real-time architecture changes what your application can credibly do with CRM data.

Key takeaways

• A CRM API gives applications programmatic access to customer-relationship data: contacts, companies, deals, pipelines, leads, and activity records. CRM data represents external prospects and customers — it's not the system of record for employees, candidates, or billing.
• Real-time pass-through CRM APIs route every request live to the source CRM with no cached replica. Sync-based CRM integrations cache data on a schedule and serve reads from that cache. The architectural choice determines data freshness, AI agent compatibility, and compliance scope.
• Most CRM data models normalize cleanly across vendors at the canonical-object level (Deal, Contact, Company, Lead, Event, Pipeline). The vendor variability shows up in lifecycle semantics, custom fields, write coverage, and event delivery — which is where unified APIs earn their keep.
• Activities (calls, notes, emails, meetings, tasks) are read-only in most CRMs and rarely emit native webhooks. Applications need polling-based change detection for activity data, regardless of how robust the CRM's webhook support is for other objects.
• Build-vs-buy depends on how many CRM integrations you need to support. One CRM is tractable to build directly. Three or more, with consistent normalization across canonical objects and unified webhook semantics, is where a CRM API saves measurable engineering time.

What is a CRM API?

A CRM API is a programmatic interface to a CRM platform's data — typically a REST API that supports reading and writing the canonical CRM objects (contacts, companies, deals, pipelines, leads) plus reading historical activity data (calls, notes, emails, tasks).

Common operations include:

• Retrieving and creating contacts and companies
• Managing deals through sales pipeline stages
• Creating and qualifying leads
• Reading historical sales activity
• Filtering and searching across records

CRM APIs focus on sales-centric customer data. They are not the system of record for employees, candidates, billing, or support tickets — which is why CRM lives as its own integration category alongside HR, ATS, accounting, and ticketing.

How does CRM API integration differ from ATS, HR, marketing, and ticketing?

CRM, ATS, HR, marketing automation, and ticketing all manage data about people — but the people, the relationships, and the canonical records are different.

What does a CRM API call actually look like?

Unified's CRM API uses one normalized endpoint structure across all supported CRM integrations. The same code works against Salesforce, HubSpot, Pipedrive, Microsoft Dynamics, or any other CRM connection — only the connection_id changes:

GET https://api.unified.to/crm/contact/{connection_id}?limit=50
Authorization: Bearer YOUR_API_KEY

Creating a deal:

POST https://api.unified.to/crm/deal/{connection_id}
Authorization: Bearer YOUR_API_KEY
Content-Type: application/json

{
  "name": "Acme Corp - Q1 Renewal",
  "amount": 50000,
  "currency": "USD",
  "stage_id": "stage_negotiation",
  "company_id": "company_12345"
}

Listing activities (events) with date filtering:

GET https://api.unified.to/crm/event/{connection_id}?limit=100&updated_gte=2026-01-01T00:00:00Z
Authorization: Bearer YOUR_API_KEY

The endpoint structure is consistent across canonical objects. Switching CRM integrations doesn't require rewriting application code.

Real-time pass-through vs. sync-based CRM access

CRM integrations fall into two architectural patterns. The choice has concrete implications for what your application can do with CRM data.

For a deeper architectural breakdown, see What is a unified API? and our guide on polling vs. webhooks.

What are the canonical CRM objects?

CRM platforms differ in feature surface, but most converge on the same core object model. Major CRMs publish detailed schemas — for example, Salesforce's Object Reference and HubSpot's CRM API objects — and the patterns rhyme across vendors. Unified normalizes these into consistent objects across integrations.

Deals

Deals represent sales opportunities moving through a pipeline.

• Full CRUD support across most CRM integrations
• Lifecycle fields: created_at, updated_at, closing_at (expected close date), closed_at (actual close)
• Tracks amount, currency, probability, stage_id, pipeline_id
• Probability may be inferred from stage or set explicitly, depending on the CRM

Vendor variability worth knowing:

• closing_at is optional and integration-dependent — some CRMs don't track expected close dates
• Stage and pipeline semantics differ across CRMs (some have global stages, some are pipeline-scoped)
• Closed/won and closed/lost are encoded differently across platforms

Contacts

Contacts represent people associated with companies or deals.

• Full CRUD support
• Includes name, title, email addresses, phone numbers, company associations
• Some CRMs combine contacts and leads into a single entity; others keep them separate
• Field-level write restrictions vary by integration

Companies

Companies (sometimes called Accounts) represent organizations.

• Full CRUD support
• Includes domain, address, industry, size, relationships to contacts and deals
• Have no won/lost lifecycle (they're not transactional)

Leads

Leads represent top-of-funnel prospects who haven't been qualified into a contact-and-deal relationship.

• Full CRUD support
• May be converted to contacts or companies through CRM-specific conversion flows
• Lifecycle semantics vary substantially across CRMs — applications shouldn't assume consistent conversion behaviour

Events (Activities)

Events represent CRM activity records: notes, meetings, emails, calls, tasks, marketing emails, form submissions, page views.

• Full CRUD support in the Unified CRM API schema (Create, List, Retrieve, Update, Remove)
• Includes type, note, meeting, email, call, task, marketing_email, form, page_view fields plus relationships (deal_ids, company_ids, contact_ids, lead_ids, user_id)
• Retrieved via list endpoints with pagination and date filtering
• No native webhooks across most CRMs — polling required for change detection on activity data

Write coverage on activity records varies by underlying CRM. Some CRMs accept writes for some activity types (notes, tasks) and not others (system-generated emails, page views). Check per-integration support if your application needs to write activity data.

Pipelines

Pipelines define deal stage progression and associated probabilities.

• CRUD operations available in the schema (Create, List, Retrieve, Update, Remove)
• Includes name, is_active, deal_probability, display_order, stages
• Pipeline configuration is typically managed in the CRM directly; write support through the API varies by underlying CRM
• Used to interpret deal stage_id values and calculate weighted pipeline metrics

What does the Unified CRM data model actually look like?

For reference, here are the canonical objects in Unified's CRM API, with their normalized fields and supported methods. The same schema applies across all 49 CRM integrations Unified supports — the underlying CRM determines vendor-specific support for individual fields and write operations.

How does real-time event delivery work for CRM data?

CRM platforms vary widely in webhook support. Some emit native webhooks for deals and contacts; others provide no webhook support at all. Even within a single CRM, certain object types emit events while others don't.

Unified handles this variability through a single webhook interface:

• Native webhooks are subscribed to and forwarded when the underlying CRM supports them (type: NATIVE in the payload)
• Virtual webhooks detect changes through polling at a configurable interval and deliver events through the same webhook interface (type: VIRTUAL in the payload)

Both native and virtual webhooks deliver the same payload structure: a data array containing the full normalized CRM records that changed. This means your application receives the updated record directly — no follow-up GET request to fetch the changed data. The fields parameter on the webhook subscription controls which fields are included in the payload (all fields by default, or a specific subset), and raw can be included to surface integration-specific custom fields on each record.

For your application, the code is identical regardless of whether the underlying CRM has native webhook support. The integration-specific implementation details are handled in the integration layer.

Coverage limits worth planning for:

• Deals, contacts, companies, and leads emit change events on most CRM integrations (native or virtual)
• Activity events (notes, calls, emails, meetings) do not emit native webhooks on most CRMs — virtual webhooks (polling-based change detection) handle these instead
• Pipeline configuration changes do not emit events on any CRM we've integrated with

For deeper coverage on event delivery patterns, see what are virtual webhooks? how they differ from sync-based webhooks.

How is identity and ownership represented in CRM APIs?

CRM objects include user_id fields representing ownership or attribution: the deal owner, the contact owner, the lead owner. These IDs reference users within the CRM itself.

• Deal owners, contact owners, and lead owners are CRM users (sales reps, account managers)
• These user IDs may correspond to HR employees in your customer's HR integration, but the mapping is application-defined — it's not automatic
• The contact, lead, or company records themselves are external customers, not employees

There are no fields that automatically link a CRM contact to an ATS candidate or HR employee. Cross-category relationships need to be defined and maintained by the application that uses both integrations.

What about security, privacy, and PII handling?

CRM data routinely contains personally identifiable information: names, emails, phone numbers, addresses, deal amounts, account information. Architecture choices affect compliance scope.

Real-time pass-through, no data stored at rest

Unified's CRM API routes every request live to the source CRM. CRM payloads are not stored at rest. CRM data is not written to logs. Requests are stateless. If your application needs to persist CRM data for reporting, analytics, or AI features, your application owns that storage — Unified isn't a sub-processor for the CRM data itself.

This affects compliance scope meaningfully. With sync-based CRM integrations, the integration vendor stores customer CRM records and is a full data sub-processor. With real-time pass-through, the integration vendor only handles credentials and operational metadata.

PII handling for AI features

CRM data being used by AI features (sales copilots, deal-summarization features, next-action recommenders) often passes through LLM context. Standard practice is to request only required fields and to filter sensitive fields before data reaches the model. Unified MCP supports field-level filtering for AI agent integrations specifically.

Compliance posture

Unified maintains SOC 2 Type II compliance, GDPR / CCPA / CPRA / HIPAA / PIPEDA alignment, TLS 1.2+ in transit, AES-256 encryption for the minimal diagnostic fields stored, SAML/OIDC SSO, role-based access control, and IP allow-listing.

What CRM API features are constrained or unavailable?

Honest constraints worth designing around:

• Activity events rarely have native webhooks. No CRM we've integrated with provides reliable native webhooks for activity records. Change detection on activity data requires polling.
• Write coverage varies by CRM. Unified's CRM API schema supports CRUD operations on Deal, Contact, Company, Lead, Event, and Pipeline. Underlying CRM support for writes — especially on activity events and pipeline configuration — varies per integration. Test write paths against each CRM you support.
• Custom fields require explicit handling. Each CRM customer's tenant has unique custom fields. Custom fields appear inside the raw object on each normalized record — request them with ?fields=raw to get the full integration payload, or ?fields=raw,raw.leadFunnelStage to request specific custom fields by name. The Metadata API surfaces schema information for discovering what custom fields exist on a customer's tenant.
• Event ordering is not guaranteed. Across CRMs, change events can arrive out of order. Your event handlers need to be idempotent.
• Rate limits vary by CRM. Salesforce, HubSpot, and Pipedrive each enforce different concurrency and per-minute limits. For webhook-based event delivery, Unified handles rate-limit coordination across integrations automatically. For direct API calls, Unified respects underlying integration rate limits and returns HTTP 429 when limits are hit — your application is responsible for backoff and retry on direct calls. Bulk operations need to plan for throttling.

Common CRM API integration use cases

Sales enablement and sales intelligence applications

Surface contact, deal, and pipeline data inside sales applications to provide context, prioritization, or coaching. Real-time access matters here because users see live CRM state.

Pipeline analytics and forecasting

Aggregate deal data across CRMs to build dashboards for pipeline health, revenue forecasting, and activity trends. This is the use case where activity polling matters most — most analytics features depend on activity data.

AI sales assistants and copilots

Summarize accounts, recommend next actions, draft outreach. AI features benefit substantially from real-time pass-through architecture: agents reason on current CRM state, not on cached snapshots that may be hours old.

Marketing and support context enrichment

Enrich communication or support flows with CRM context (deal stage, account size, recent activity) without duplicating CRM data into a separate database.

Cross-platform CRM consolidation for B2B SaaS products

Build features that work across whichever CRM the customer uses. Unified MCP supports this pattern for AI agents specifically — the same agent can read deal context from Salesforce for one customer and HubSpot for another, with no per-CRM logic in the agent.

Direct vs. Unified — when to choose each

Build directly if

• You support exactly one CRM and have no near-term plans to add another
• You need deep vendor-specific functionality not in the normalized schema
• You have engineering capacity to maintain per-CRM auth, webhook, and rate-limit infrastructure

Use Unified if

• You support (or plan to support) multiple CRMs across customers
• You want time-to-first-customer measured in minutes, not weeks
• You'd rather not build polling infrastructure for activity data
• You want consistent webhook semantics across CRMs
• You're building AI features where real-time CRM state matters

For broader context on integration architecture choices, see our breakdown of ETL vs. iPaaS vs. unified API.

Best practices for CRM API integration

• Treat CRM contacts as external customers, not as employees or candidates
• Design your application code for vendor variability — assume lifecycle semantics differ across CRMs
• Plan for polling-based change detection on activity data
• Request only the fields your application needs (request scope tightening reduces both cost and PII exposure)
• Handle ownership (user_id) separately from contact identity
• Build idempotent event handlers — assume events arrive out of order and may be delivered more than once
• Monitor connection health and rate-limit responses per integration

Frequently asked questions

What is a CRM API?

A CRM API is a programmatic interface to a CRM platform's data, supporting reading and writing of customer-relationship records: contacts, companies, deals, pipelines, leads, and activity events.

Which CRM integrations does Unified support?

Unified supports 49 CRM integrations including Salesforce, HubSpot, Pipedrive, Zoho CRM, Microsoft Dynamics 365 Sales, Microsoft Dynamics 365 Customer Engagement, Close, Copper, Insightly, Keap, ActiveCampaign, Affinity, Apollo.io, Attio, Bullhorn, Freshsales CRM, Gainsight, Outreach.io, Salesflare, Salesloft, Wealthbox, Zendesk Sell, and others — accessed through a single normalized CRM API. The full integration list is available at unified.to/integrations/crm.

Are CRM updates real-time through Unified?

Reads always hit the source CRM live — no caching layer. Updates are delivered via native webhooks where the CRM supports them, and via virtual webhooks (polling-based change detection) where it doesn't. Activity data and pipeline configuration changes require polling on most CRMs.

Can I create and update CRM records through the API?

Yes, on most CRM integrations. Deals, contacts, companies, and leads generally support full CRUD operations. Activities are read-only across most CRMs. Pipeline configuration is read-only and managed in the CRM directly.

Does Unified store CRM data?

No. The CRM API is real-time pass-through — every request is routed live to the source CRM. CRM payloads are not stored at rest. CRM data is not written to logs. If your application needs to persist CRM data for analytics or AI, your application owns that storage.

How does CRM differ from marketing automation, ATS, or ticketing?

CRM manages external customer relationships and sales pipelines. Marketing automation manages campaign execution and outbound messaging. ATS manages recruiting and hiring data. Ticketing manages support cases. The records are distinct, the lifecycle semantics differ, and cross-category relationships need to be defined explicitly by the application.

How does Unified handle CRM custom fields?

Custom fields appear inside the raw object on each CRM record. Access them by adding ?fields=raw to your request (returns the complete integration payload) or ?fields=raw,raw.customerSegment to request specific custom fields by name. The Metadata API provides schema discovery for finding what custom fields exist on a customer's tenant. For completely custom objects or endpoints not in the normalized schema, the Passthrough API supports direct CRUD operations against the underlying CRM while keeping the unified authentication and connection management.

What's the architectural difference between real-time pass-through and sync-based CRM APIs?

Real-time pass-through CRM APIs route every request live to the source CRM with no data stored at rest. Sync-based CRM integrations cache CRM data on a schedule and serve reads from that cache. The choice affects data freshness, latency, compliance scope, AI agent reliability, and how much of your application's logic depends on data being current vs. eventually consistent.

Final thoughts

CRM API integration is well-trodden territory — most B2B SaaS products eventually need it. The architectural choices that matter aren't which CRM platforms to support; the canonical object models converge cleanly across vendors. The choices that matter are whether your application reads CRM data live or from a cache, whether you build per-CRM auth and webhook infrastructure or use a normalized layer, and whether your AI features can credibly act on real-time CRM state.

Unified.to provides a real-time CRM API across 49 CRM integrations — including Salesforce, HubSpot, Pipedrive, Microsoft Dynamics 365 Sales, Zoho CRM, Close, Copper, ActiveCampaign, Bullhorn, Apollo.io, and others — through a single normalized schema and webhook interface.

Start a free trial or book a demo to see it work.