Enterprise SaaS Integration Platform: Real-Time Unified APIs Explained

When looking for an integration platform with unified API support and real-time data fetching for your enterprise SaaS product, engineering leaders face a binary architectural choice: cache third-party data and inherit the compliance risk, or proxy the data in real-time and maintain strict data residency.

If you are searching for a platform that truly supports enterprise-grade compliance, you have already ruled out half the market. Most "unified API" vendors run a sync-and-store pipeline: they poll third-party APIs on a schedule, cache the responses in their own database, and hand you stale JSON. That architecture collapses the moment a Fortune 500 security team asks where their customer PII is being written to disk.

Organizations do not purchase isolated software silos; they purchase nodes in a massive, interconnected graph of data. The integration problem is not shrinking. According to independent industry research, the average tech company pays for 275 SaaS applications. Despite aggressive consolidation efforts by CFOs, SaaS spending grew by 9.1% and the average tech stack expanded by 2.2% in 2024. Tool fragmentation is a permanent reality.

Enterprise buyers expect your product to read from their CRM, write back to their accounting system, and sync employee states with their HRIS. But building these native integrations in-house scales poorly, and routing them through legacy middleware introduces unacceptable security liabilities.

This guide is for B2B SaaS product and engineering leaders who need real-time, pass-through data across CRMs, HRIS, ATS, ticketing, and accounting systems—without failing a SOC 2 review or building a 15-person integrations team. We will break down the architectural realities of evaluating an enterprise SaaS integration platform, examine why legacy sync-and-store models fail security reviews, expose the hidden engineering costs of maintaining custom connectors, and show what a zero-storage unified API actually looks like in production.

Why Enterprise SaaS Needs Real-Time Data Fetching

Key Takeaways:

• Storing third-party data in an integration middleware layer introduces massive compliance and financial risk.
• Sync-and-store architectures create data residency liabilities and synchronization delays.
• Pass-through API architectures fetch data in real-time, leaving no PII on intermediary servers.

For years, the standard approach to B2B integrations involved a sync-and-store architecture. Platforms using this model—such as Merge.dev—periodically poll third-party APIs, download the customer's data, normalize it, and store it in their own intermediary databases. Your application then queries this cached data rather than the live third-party system.

From a purely theoretical standpoint, caching reduces latency. In the reality of enterprise software sales, it creates a massive compliance liability. When your prospect's IT team is juggling hundreds of vendors, they are not going to approve one more that unnecessarily hoards their data.

There are three concrete reasons real-time fetching wins enterprise deals:

1. Data Residency Compliance: GDPR, DORA, HIPAA, and most APAC regulations require you to know exactly where PII physically resides. A middleware that caches CRM contacts in a US-region database will fail an EU DPA review, full stop. When you use a sync-and-store platform, you are actively duplicating your customer's most sensitive data into a third-party database that you do not control.
2. Freshness for AI Agents: LLM tool-calling on stale cached data produces wrong answers. If an AI agent quotes a deal amount from a 6-hour-old cache, and the sales rep just updated it in Salesforce, you have an integrity problem that no amount of prompt engineering can fix.
3. Breach Blast Radius: The financial stakes are unforgiving. Research shows the average cost of a healthcare data breach reached $9.77 million in recent years. If your integration vendor is caching PHI, you have inherited their breach risk. Pass-through architectures eliminate the target entirely—there is nothing sitting in a warehouse to steal.

The practical test for any vendor during an evaluation is simple. Ask them where a Salesforce Contact record physically lives after your customer connects their account. If the answer involves any database, warehouse, or object store owned by the vendor, you are looking at a sync-and-store system dressed up in unified API marketing.

The Hidden Costs of Building Integrations In-House

Faced with the security risks of third-party caching, many engineering leaders default to building point-to-point integrations in-house rather than adopting tools to ship enterprise integrations without an integrations team. A senior engineer looks at the HubSpot API documentation, estimates a two-week build time, and the project gets greenlit.

This is a trap. Engineering leaders consistently underestimate integration TCO by an order of magnitude. Industry analysis on build-vs-buy for integrations shows that initial development often accounts for less than 30% of the total cost over an integration's lifespan. The remaining 70%+ is ongoing maintenance, undocumented edge cases, and the mathematical impossibility of scaling custom code.

Here is what actually happens when you build and maintain just a handful of integrations in-house:

Multiply that by 20, 50, or 100 integrations, and this maintenance burden consumes your entire roadmap. Engineering teams end up dedicating entire pods simply to keeping existing connections alive. Meanwhile, your competitors are shipping core product features.

The opportunity cost makes building them mathematically unviable for mid-market SaaS companies. For a deeper cost breakdown, see our 2026 Unified API Buyer's Guide.

Embedded iPaaS vs. Unified API: Which Architecture Wins?

When evaluating integration platforms to offload this maintenance burden, buyers generally encounter two distinct architectural categories: embedded iPaaS and unified APIs. Picking the wrong one will burn a year of engineering time.

Embedded iPaaS (Visual Workflow Builders)

Embedded Integration Platform as a Service (iPaaS) solutions—such as Paragon or Workato Embedded—rely heavily on visual workflow builders. They allow product managers or implementation engineers to drag and drop nodes on a canvas to define integration logic.

While visual builders demo incredibly well to non-technical stakeholders, they introduce severe friction for software engineering teams:

• Workflows are opaque state machines: Code-first engineering teams rely on version control, automated testing, CI/CD pipelines, and code reviews. Visual workflows exist outside of this ecosystem.
• Multi-tenancy is bolted on: A workflow customized for Customer A cannot easily be updated without risking regressions for Customer B.
• Debugging is a nightmare: When a visual workflow fails silently, debugging requires logging into a third-party UI, clicking through specific execution runs, and trying to decipher visual logs rather than reading a stack trace with a request ID.

This architecture does not scale well for complex, high-throughput enterprise use cases where developers need programmatic control over errors and retries.

Developer-First Platforms and Unified APIs

A true unified API abstracts away the differences between underlying providers completely. You expose one REST or GraphQL contract across dozens of providers. Your engineering team writes normal application code against a unified /crm/contacts endpoint, and the platform routes to Salesforce, HubSpot, Pipedrive, or Zoho behind the scenes.

The trade-off between unified API vendors comes down to what happens under the hood:

• Code-first platforms (Nango-style) require you to write and maintain custom integration scripts in TypeScript inside their ecosystem (if (provider === 'hubspot') { ... }). You still own the maintenance burden—the vendor just gives you scaffolding.
• Sync-and-store platforms (Merge.dev-style) run background jobs that cache data in their database. You get a clean API but inherit compliance liabilities and data staleness.
• Pass-through platforms proxy every request to the upstream API in real time, normalize the response in-transit, and never persist third-party data.

flowchart LR
  A[Your SaaS App] -->|GET /crm/contacts| B[Unified API Proxy]
  B -->|Real-time proxy| C[Salesforce API]
  B -->|Real-time proxy| D[HubSpot API]
  B -->|Real-time proxy| E[Pipedrive API]
  C -->|Native response| B
  D -->|Native response| B
  E -->|Native response| B
  B -->|Normalized JSON| A

Engineering teams overwhelmingly prefer unified APIs because they treat integrations as standard contracts. You write one integration to the unified API, and you instantly support dozens of underlying platforms. When evaluating which unified API is best for enterprise SaaS, the deciding factor usually comes down to how the platform handles data normalization and custom fields without storing data.

Real-Time Unified API Solutions for Enterprise SaaS

Truto was architected specifically to solve the tension between developer velocity and enterprise compliance. It provides the abstraction of a unified API with the strict data residency of a pass-through proxy.

The design principle is simple: third-party customer data never touches Truto's storage layer. Every request from your app triggers a real-time call to the upstream API, gets normalized in-flight, and is returned to you. Nothing is written to disk.

Declarative Mappings Instead of Integration-Specific Code

Most unified API platforms maintain separate code paths for each integration behind the scenes. They have integration-specific database columns, dedicated handler functions (salesforce_contacts.ts, hubspot_contacts.ts), and hardcoded business logic. Adding a new integration requires writing new code and deploying it.

Truto operates with zero integration-specific code. There is a single generic execution engine that reads a declarative configuration describing how to talk to any third-party API, plus a JSONata mapping that translates between the native schema and Truto's unified model.

A typical unified contact mapping looks like this at the conceptual level:

{
  "unified_field": "first_name",
  "provider_expression": "FirstName",
  "provider": "salesforce"
}

For HubSpot, the same unified field maps to properties.firstname. It uses the same code path and the same normalization engine. Zero if-provider branches. Integration behavior is defined entirely as declarative data. Read more in Zero Integration-Specific Code: How to Ship API Connectors as Data-Only Operations.

Real-Time Proxy with In-Flight Normalization

When your application requests a normalized list of contacts, the architecture flows like this:

sequenceDiagram
  participant App as Your App
  participant Truto as Truto Proxy Layer
  participant Engine as Execution Engine
  participant Upstream as Target CRM (e.g., Salesforce)
  App->>Truto: GET /unified/contacts
  Truto->>Engine: Fetch Declarative JSONata Mapping
  Truto->>Truto: Resolve OAuth token from vault
  Truto->>Upstream: Native API call with auth
  Upstream-->>Engine: Raw Provider Response
  Engine->>Engine: Apply JSONata mapping in-memory
  Engine-->>Truto: Normalized JSON
  Truto-->>App: Normalized unified response
  Note over Truto: Zero PII persisted to disk

Because the translation happens entirely in-memory using JSONata streaming transformations, Truto never writes the payload to a database. The only things Truto stores are the OAuth tokens needed to make the call and metadata like connection status. It is a true real-time pass-through architecture.

Compliance Implications

This approach yields massive benefits for enterprise SaaS companies:

1. Zero Data Retention: You can confidently tell enterprise IT buyers that your integration middleware does not store their PII. This accelerates security reviews. SOC 2 Type II scope is dramatically narrower, HIPAA BAAs become trivial (no PHI in the vendor's environment), and GDPR data residency is a non-issue.
2. Instant Updates: Because integrations are data operations rather than code operations, Truto can push fixes for upstream API changes instantly without deploying new code.
3. Real-Time Accuracy: Your application always receives the exact state of the third-party system at the moment of the request. There are no sync delays, polling intervals, or cache invalidation headaches.

Real-Time Unified API Product Specifications

Marketing pages describe every platform as "real-time." The specification below is the concrete contract of what a pass-through unified API for enterprise SaaS should actually deliver. Use it as a scorecard when evaluating any integration platform with unified API and real-time data claims.

The important thing here is what is not in the spec. There is no scheduled sync job for reads. There is no shadow copy of Salesforce contacts sitting in a vendor warehouse. There is no eventual consistency window between a rep updating a deal in HubSpot and your app seeing that update. When the product spec explicitly forbids storage of response bodies, downstream compliance conversations get much shorter.

How Live Data Fetching Works for Enterprise SaaS

Understanding what actually happens on the wire between your application, the unified API, and the upstream provider is the difference between shipping compliant enterprise SaaS integration unified API contracts and getting stuck in a security review for six months.

Here is the request lifecycle when your product calls GET /unified/crm/contacts?integrated_account_id=abc123 for a customer connected to Salesforce.

1. Authenticate the caller. The unified API validates your API token, resolves which environment and integrated account the request belongs to, and loads the connection context (encrypted OAuth tokens, provider metadata, per-connection overrides). No third-party record is touched at this stage.

2. Load the mapping, not the data. The platform fetches the declarative integration config (base URL, endpoints, pagination strategy, auth scheme) and the JSONata mapping for crm.contacts. Both are configuration, not customer data.

3. Refresh credentials if needed. Truto refreshes OAuth tokens shortly before they expire so the call to the upstream never fails because of a stale token. Refresh happens inline in the request path when required, with idempotency protection so concurrent requests do not double-refresh.

4. Transform the request. Unified query parameters (limit, updated_after, custom filters) are translated into the provider's native format via a JSONata expression - a SOQL WHERE clause for Salesforce, a filterGroups array for HubSpot, an OData $filter for Microsoft Graph. The same generic mapper executes all three; the difference lives entirely in the mapping data.

5. Call the upstream API in real time. The proxy layer executes a live HTTPS request to the provider (https://your-instance.my.salesforce.com/services/data/v59.0/query) using the just-refreshed token. This is the source of truth. The upstream response includes the exact state of the record as of that millisecond.

6. Normalize in-flight. The provider response is streamed through the JSONata mapping engine. Field renames, type coercion, phone number splits, address flattening, custom field extraction, and per-connection overrides all execute in-memory against the response object. The original provider payload is attached to each record as remote_data so callers that need raw fields never have to fall back to a proxy call.

7. Return and forget. The normalized response is serialized to your caller. The provider payload and the normalized output are not written to any database, object store, or queue. Only structured operational logs are retained (request ID, integration name, upstream status code, latency) - never response bodies.

sequenceDiagram
  participant App as Your SaaS App
  participant API as Unified API
  participant Vault as Token Vault
  participant Engine as Mapping Engine
  participant CRM as Upstream CRM
  App->>API: GET /unified/crm/contacts
  API->>Vault: Load OAuth token + config
  Vault-->>API: Encrypted token, mapping ref
  API->>API: Refresh token if near expiry
  API->>CRM: Live HTTPS call with bearer token
  CRM-->>API: Native response (SOQL result set)
  API->>Engine: Evaluate JSONata per record
  Engine-->>API: Normalized contacts
  API-->>App: Unified JSON, remote_data attached
  Note over API,Engine: No response body written to disk

What This Means in Practice

• Every read is authoritative. When a sales rep updates a deal in Salesforce and your AI agent queries it three seconds later, it sees the new value. There is no polling interval to tune, no cache TTL to invalidate, no reconciliation job to wait for.
• Data residency is a non-question. The upstream provider holds the data. Truto holds the token. Your application holds the response for the duration of the HTTP request. There is nothing in a middleware database to region-lock.
• Writes are just as immediate. POST /unified/crm/contacts translates and forwards the create to the upstream in real time, returns the provider's ID synchronously, and never queues the write in an intermediate store. Your customer sees the record appear in Salesforce before your API response returns.
• Failure modes are honest. If the upstream is down, your request fails with the upstream's status code and body. There is no illusion of success created by writing to a cache and reconciling later. Your circuit breakers, retries, and user-facing error messages get to see the real state of the world.
• Latency is predictable. The mapping layer adds single-digit milliseconds on top of the upstream call. The dominant cost is the upstream provider's own response time, which you would pay in any architecture.

For enterprise SaaS teams shipping into regulated industries, this is the only architecture that survives contact with a real security review. It is also the only architecture that gives AI features and user-facing dashboards access to trustworthy state.

Technical Quickstart: Unified API Fetch

Enough architecture. Here is what real-time unified API access looks like on the wire. Every example below issues a live upstream call for every request. No cached reads, no background sync, no eventual consistency.

Prerequisites: a Truto API token and an integrated_account_id for a customer who has connected an account (Salesforce, HubSpot, Pipedrive, or any other supported CRM works identically).

List Contacts Across Any CRM

The same request works whether the connected account is Salesforce, HubSpot, Pipedrive, Zoho, or Close. The platform selects the correct upstream endpoint, auth scheme, and pagination strategy from the integration config.

curl -X GET "https://api.truto.one/unified/crm/contacts?integrated_account_id=abc123&limit=50" \
  -H "Authorization: Bearer $TRUTO_API_TOKEN"

Response (identical shape across every provider):

{
  "result": [
    {
      "id": "003xx000000001",
      "first_name": "Jane",
      "last_name": "Doe",
      "name": "Jane Doe",
      "title": "VP Engineering",
      "account": { "id": "001xx000000002" },
      "email_addresses": [
        { "email": "jane@acme.com", "is_primary": true }
      ],
      "phone_numbers": [
        { "number": "+1-555-0123", "type": "phone" }
      ],
      "created_at": "2024-01-15T10:30:00Z",
      "updated_at": "2026-06-20T14:15:00Z",
      "custom_fields": {
        "Lead_Score_Q3__c": 92,
        "Regional_Manager__c": "005xx000000099"
      },
      "remote_data": {
        "Id": "003xx000000001",
        "FirstName": "Jane",
        "LastName": "Doe",
        "Email": "jane@acme.com"
      }
    }
  ],
  "next_cursor": "eyJvZmZzZXQiOjUwfQ==",
  "result_count": 50
}

Every record ships with remote_data attached: the untouched upstream payload. If the unified schema does not cover a field you need, read it from remote_data without a second network hop.

Filter for Freshness (Real-Time by Definition)

Enterprise dashboards and AI agents typically want records updated since the last poll. The unified schema exposes an updated_at filter that maps to the provider's native filter mechanism (SOQL for Salesforce, filterGroups for HubSpot, and so on):

curl -X GET "https://api.truto.one/unified/crm/contacts\
?integrated_account_id=abc123\
&updated_at[gt]=2026-08-19T00:00:00Z\
&limit=100" \
  -H "Authorization: Bearer $TRUTO_API_TOKEN"

Because this is a pass-through call, the response reflects the upstream's state at the millisecond of the request - not the last time a sync job ran.

Fetch a Single Record by ID

curl -X GET "https://api.truto.one/unified/crm/contacts/003xx000000001?integrated_account_id=abc123" \
  -H "Authorization: Bearer $TRUTO_API_TOKEN"

Create a Contact (Write-Through, No Queue)

curl -X POST "https://api.truto.one/unified/crm/contacts?integrated_account_id=abc123" \
  -H "Authorization: Bearer $TRUTO_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "first_name": "Jane",
    "last_name": "Doe",
    "email_addresses": [{ "email": "jane@acme.com", "is_primary": true }],
    "phone_numbers": [{ "number": "+1-555-0123", "type": "phone" }]
  }'

The write is forwarded synchronously. When the response returns, the record exists in Salesforce (or wherever). No background job, no reconciliation window.

Paginate Through Every Contact

Every upstream pagination strategy (cursor, page, offset, link-header, range) collapses into the same next_cursor contract:

NEXT=""
while :; do
  RESP=$(curl -s "https://api.truto.one/unified/crm/contacts\
?integrated_account_id=abc123&limit=100&next_cursor=$NEXT" \
    -H "Authorization: Bearer $TRUTO_API_TOKEN")
 
  echo "$RESP" | jq -c '.result[]' >> contacts.jsonl
  NEXT=$(echo "$RESP" | jq -r '.next_cursor // empty')
  [ -z "$NEXT" ] && break
done

Same loop, whether the underlying provider is offset-paginated HubSpot or cursor-paginated Salesforce.

Read a Custom or Unmapped Object

When you need to hit an upstream endpoint the unified model does not cover (a Salesforce custom object, a HubSpot custom property endpoint, a NetSuite SuiteQL query), use the pass-through Custom API. It reuses the same auth and connection context - no separate credentials, no different SDK:

curl -X GET "https://api.truto.one/custom/services/data/v59.0/query\
?integrated_account_id=abc123\
&q=SELECT+Id,Name+FROM+Custom_Deal__c+WHERE+Stage__c='Closed+Won'" \
  -H "Authorization: Bearer $TRUTO_API_TOKEN"

Register a Webhook Subscription

Unified webhook events normalize provider notifications into canonical record:* events:

curl -X POST "https://api.truto.one/webhook" \
  -H "Authorization: Bearer $TRUTO_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://yourapp.com/webhooks/truto",
    "event_types": ["record:created", "record:updated", "record:deleted"]
  }'

When an upstream contact is updated, your endpoint receives:

{
  "event": "record:updated",
  "payload": {
    "resource": "crm/contacts",
    "integrated_account_id": "abc123",
    "records": [ { "id": "003xx000000001", "first_name": "Jane", "...": "..." } ],
    "raw_event_type": "contact.propertyChange",
    "raw_payload": { "...": "..." }
  }
}

Same envelope shape whether the source event was HubSpot's contact.propertyChange, Salesforce's Change Data Capture, or HiBob's employee.updated.

Handle Rate Limits Like Any Other HTTP Client

Upstream 429s pass through unchanged, but with normalized IETF ratelimit-* headers so you can apply your own backoff strategy:

curl -i "https://api.truto.one/unified/crm/contacts?integrated_account_id=abc123" \
  -H "Authorization: Bearer $TRUTO_API_TOKEN"
 
# HTTP/1.1 200 OK
# ratelimit-limit: 1000
# ratelimit-remaining: 847
# ratelimit-reset: 1755590400

A minimal client with preemptive backoff:

async function fetchContacts(accountId: string, cursor?: string) {
  const url = new URL('https://api.truto.one/unified/crm/contacts')
  url.searchParams.set('integrated_account_id', accountId)
  if (cursor) url.searchParams.set('next_cursor', cursor)
 
  const res = await fetch(url, {
    headers: { Authorization: `Bearer ${process.env.TRUTO_API_TOKEN}` }
  })
 
  const limit = Number(res.headers.get('ratelimit-limit') ?? 0)
  const remaining = Number(res.headers.get('ratelimit-remaining') ?? 0)
  if (limit > 0 && remaining / limit < 0.1) {
    const reset = Number(res.headers.get('ratelimit-reset') ?? 0)
    await sleep(Math.max(0, reset * 1000 - Date.now()))
  }
 
  if (!res.ok) throw new Error(`Truto ${res.status}: ${await res.text()}`)
  return res.json()
}

Every example above works the same regardless of which upstream CRM the customer connected. That is the point of a unified API - your code does not branch on provider, and it never talks to a cache.

Handling Custom Objects and Rate Limits at Enterprise Scale

The true test of any unified API is how it handles the edge cases that define enterprise software—specifically, custom data models and aggressive rate limits. Both are hard because they violate the assumptions of naive unified API design.

Per-Customer Data Model Overrides

Unified APIs are excellent for standard fields like first_name and email. But every Salesforce enterprise tenant is heavily customized. Customer A might have a custom field called Lead_Score_Q3__c. Customer B has Regional_Manager__c.

Legacy unified APIs force you to either drop these custom fields on the floor or write brittle, customer-specific code forks to extract them. Truto handles this natively through a 3-level configuration hierarchy:

1. Global default mapping: Shipped by Truto for each provider.
2. Tenant-level overrides: Your product's global customizations to the unified schema.
3. Per-connection overrides: Per-customer JSONata expressions that reshape specific fields for a single tenant ID.

If a Fortune 500 buyer needs a custom field mapped to your unified model, you simply upload a specific JSONata mapping for their connection. The generic execution engine applies this override dynamically. You get custom, per-tenant data handling without forking a single line of your application code.

Standardized Rate Limit Handling

Every SaaS API enforces rate limits, and every vendor reports them differently. Some use HTTP headers (Salesforce uses Sforce-Limit-Info, GitHub uses X-RateLimit-*). Some put the limit inside the JSON response body. Some simply return an HTTP 429 error with no context.

Here is a common vendor lie: "We handle rate limits for you." What that usually means is the integration platform silently retries failed requests with hidden exponential backoff, swallows 429 errors, and quietly builds up a queue that delays your writes by hours. If a background sync job hits a rate limit, automatic retries might exhaust the customer's remaining quota, bringing down their entire production CRM. This is dangerous for real-time use cases and often violates terms of service.

Truto takes a highly objective, developer-first approach. It does not silently retry, throttle, or apply backoff on rate limit errors. Instead, Truto normalizes the chaotic upstream rate limit information into standardized IETF headers on every response:

HTTP/1.1 429 Too Many Requests
Content-Type: application/json
ratelimit-limit: 1000
ratelimit-remaining: 0
ratelimit-reset: 1678901234
 
{
  "error": "Upstream provider rate limit exceeded"
}

When a provider returns an HTTP 429, Truto passes that exact error directly to your application, along with the normalized headers.

This puts more responsibility on your engineering team, but it is the only architecture that works for production systems. You own the retry policy. You can prioritize critical user-facing requests over background syncs based on the exact ratelimit-remaining value, rather than fighting against an opaque middleware queue.

Real-Time Performance at Scale

The legitimate objection to a pure pass-through architecture is performance. If every read is a live upstream call, does that not blow up your p99 latency and cap throughput at whatever the slowest provider can serve?

In practice, the numbers are less alarming than the intuition. Here is what actually determines performance for a real-time unified API in production.

The Latency Budget

A typical unified API request breaks down like this:

The upstream is over 90% of the latency budget. The unified API adds a small overhead on top of the upstream call it would have made anyway - the same latency you would pay if you called the provider directly, plus mapping cost. There is no way to make Salesforce faster; you can only stop making it slower.

Concurrency, Not Batch, Is the Unlock

Sequential loops over enterprise CRMs are the killer, not the per-request latency. The right pattern for large reads is a bounded concurrent fan-out with pagination:

import pLimit from 'p-limit'
 
async function syncAllContacts(accountId: string) {
  const limit = pLimit(10)
  let cursor: string | undefined
  const pages: Promise<unknown>[] = []
 
  do {
    const page = await fetchContacts(accountId, cursor)
    cursor = page.next_cursor
    pages.push(
      limit(() => processBatch(page.result))
    )
  } while (cursor)
 
  await Promise.all(pages)
}

The pagination cursor is inherently sequential (each cursor depends on the previous response), but downstream processing runs in parallel. In production, this pattern comfortably handles hundreds of thousands of records without hitting provider rate limits, because the concurrency limit is under your control.

Token Refresh Does Not Block

A common failure mode of naive integration middleware is a thundering herd on OAuth refresh: an access token expires, N in-flight requests all try to refresh simultaneously, and the provider returns 400s to all but one. The platform refreshes OAuth tokens shortly before they expire, and concurrent refreshes for the same account are coalesced so only a single refresh call goes to the provider. Your throughput is not capped by refresh contention.

Idempotency for Writes

Real-time writes are more dangerous than reads because retries can create duplicates. The unified API supports client-supplied idempotency keys on write endpoints:

curl -X POST "https://api.truto.one/unified/crm/contacts?integrated_account_id=abc123" \
  -H "Authorization: Bearer $TRUTO_API_TOKEN" \
  -H "Idempotency-Key: create-jane-doe-2026-08-19" \
  -H "Content-Type: application/json" \
  -d '{ "first_name": "Jane", "last_name": "Doe" }'

Combined with circuit breakers on your side and structured error responses from ours, this lets you retry safely without inventing your own deduplication layer.

When You Genuinely Need Cached Reads

Some workloads legitimately need SQL-style access to historical data - analytical dashboards, cohort queries, backfills. For those, the platform ships an opt-in synced read layer that you enable per query via a truto_super_query parameter. It is off by default. Compliance-sensitive endpoints stay pass-through, and analytical endpoints can query a replica when the customer's DPA permits. The important part is that it is a per-request opt-in, not the default architecture.

What Predictable Real-Time Looks Like in Production

• p50 latency tracks the upstream. If Salesforce returns in 180 ms, unified reads return in roughly 190-210 ms.
• p99 latency is dominated by upstream tails and inline token refresh. Circuit breakers on your side keep this in check.
• Throughput scales with concurrency, not batch endpoints. Fan out with a p-limit-style bound and respect the normalized ratelimit-remaining header.
• There is no cache to warm, invalidate, or lose. Cold-start behavior is identical to steady-state behavior.

For real-time-critical paths - AI agents making tool calls, user-facing dashboards, live approval flows - this is the only architecture that gives you predictable, honest performance characteristics. You are paying the upstream's real cost, not hiding it behind a queue.

Evaluating Enterprise Integration Platforms

If you are shortlisting vendors to solve your integration debt, the technical evaluation should be brutal and specific. Marketing pages will all say "real-time," "secure," and "unified." The scorecard below separates the actual pass-through platforms from the sync-and-store products dressed up in unified API language. Cross-reference it with our 2026 Unified API Benchmark when building your shortlist.

Architecture and Data Handling

• Data retention policy in writing. "Zero storage of customer PII" must be explicit in the Data Processing Agreement, not just on a marketing page. Ask for the DPA before the sales call.
• Real-time proxy vs. cached read. Ask for a request-response trace showing the upstream API call happens on every single request. If the vendor cannot produce one, they are caching.
• Storage regions. For any data the vendor does persist (tokens, connection metadata, logs), verify the region topology and data residency options.
• Sub-processor list. Enterprise procurement will ask. Get it up front.

Developer Experience

• Custom object support without code forks. Verify per-connection schema overrides through a live demo, not a slide deck. Ask the vendor to add a custom field for a hypothetical customer in front of you.
• Escape hatch to raw APIs. A Custom or Proxy API endpoint that reuses the same auth is non-negotiable. Unified schemas will always lag behind provider APIs.
• Local SDK and CLI. Does the vendor ship a CLI you can script against in CI, or is everything a dashboard click?
• Error observability. Structured error objects, request IDs in every response, and log forwarding to your Datadog/Splunk/Sentry stack.

Operational Behavior

• 429 pass-through behavior. Confirm the platform surfaces upstream rate limit errors and normalizes headers rather than applying silent retries that exhaust customer quotas.
• OAuth token lifecycle. Ask how refresh contention is handled, how revocations surface, and whether refreshes are inline or batched.
• Webhook reliability. Signed outbound delivery, retry semantics, and the ability to verify signatures with a documented algorithm are minimum requirements.
• Idempotency support on writes. Client-supplied idempotency keys, or at minimum documented request de-duplication behavior.

Commercial and Compliance

• OAuth app ownership. You should be able to bring your own OAuth apps. Vendor-managed apps become a lock-in and a shared-quota problem at enterprise scale.
• Multi-category coverage. CRM alone is table stakes. You need HRIS, ATS, ticketing, accounting, knowledge base, and calendar capabilities under one contract, or you will be integrating multiple unified API vendors.
• SOC 2 Type II and ISO 27001. Non-negotiable baseline certifications for enterprise deals. Ask for the report, not just the badge.
• HIPAA BAA availability. Required for healthcare SaaS. A pass-through architecture makes this trivial for the vendor to sign; a sync-and-store architecture makes it expensive or impossible.

If a vendor scores poorly on the architecture and data handling section, no amount of DX polish or feature coverage will save the enterprise deal. Start there.

The Strategic Reality of Enterprise Integrations

Building a scalable integration strategy requires acknowledging the painful realities of software engineering. Upstream APIs will break. Documentation will be wrong. Enterprise customers will demand custom fields, and security teams will reject any architecture that unnecessarily replicates their data.

Attempting to build and maintain dozens of point-to-point connections in-house is a massive misallocation of engineering resources. Relying on sync-and-store platforms trades short-term convenience for long-term compliance liabilities.

By adopting a real-time, pass-through unified API with declarative mappings, you decouple your core product from the chaos of third-party APIs. You empower your sales team to say "yes" to complex enterprise integration requirements, protect your engineering team from drowning in maintenance debt, and guarantee the data freshness required by modern AI agents.