---
title: "Unified.to Architecture"
url: "https://docs.unified.to/concepts/architecture"
description: "How Unified.to's real-time pass-through architecture differs from a sync-and-store unified API."
---
Updated: September 19, 2026 · Author: Roy Pereira

# Unified.to Architecture

[Unified.to](http://unified.to/) is a real-time pass-through unified API. Every request routes directly to the source API and returns current data. End-customer data isn't stored, cached, or logged at rest on our side.

Put our architecture next to a sync-and-store unified API and the high-level boxes may look the same, but the difference is in the flows: their order, number, and direction.

## [Unified.to architecture](#unifiedto-architecture-1)

![Unified.to real-time pass-through architecture diagram](/_ipx/q_80/images/unified_realtime_architecture_diagram.png)

The dashed line marks the boundary between our infrastructure and yours. Everything to the left, the source API and the Unified.to API, holds no data at rest. Everything stored, your database and any vector store feeding your AI app, sits on your side. We move the data; we don't keep it. The only things that persist are the connection ID and minimal operational metadata.

### [API: direct passthrough](#api-direct-passthrough)

An on-demand read or write. Following the numbered path in the diagram:

1. Your server calls the Unified.to API, using the connection ID to identify the account.
2. [Unified.to](http://unified.to/) transforms the call (its pagination, query parameters, and payload) into the source API's format and routes it to the source.
3. The source API responds.
4. Unified.to transforms the response in memory into a normalized object and returns it to your server.

You paginate and filter using a single unified method (offset/limit/query/updated\_gte), regardless of how the source API expects those parameters. Dates are ISO, values are validated, and raw source data is returned alongside the normalized object.

### [Virtual webhooks: scheduled](#virtual-webhooks-scheduled)

Most source APIs don't offer native webhooks. For those, Unified.to delivers events on a schedule you set:

1. On an interval you configure, as frequent as every minute, Unified.to checks the source API for changes.
2. Changed records return to Unified.to.
3. Unified.to delivers the event to your endpoint, with the changed records in the payload.

There's usually no follow-up fetch, because the event carries the data. Checks that find no change are not billed.

Rate limits, backoff, and retries are handled for you. If your endpoint is unavailable, we retry three times immediately from memory, then switch to a Fibonacci backoff that continues for up to two weeks.

Those longer retries hold a cursor, not your records: each attempt re-reads the page from the source and dispatches it fresh. Nothing sits in a delivery queue, and no end-customer data is stored, even on failure.

→ [**Understanding virtual webhooks**](/concepts/virtual%5Fwebhooks#virtual-vs-native-webhooks-comparison)

### [Native webhooks](#native-webhooks)

Where the source API supports native [webhooks](/reference/webhooks):

1. The source API pushes the event to Unified.to.
2. Unified.to delivers it to your endpoint on the same interface as virtual webhooks.

Your code consumes one event model and never branches on which delivery path an integration uses.

### [Where the data lands](#where-the-data-lands)

All three paths deliver to your server, not ours. From there the data flows into your own database and, for AI products, into your embedding model and vector store feeding your application. The storage happens in your infrastructure. Unified.to holds none of it.

## [Sync-and-store: the difference is custody](#sync-and-store-the-difference-is-custody)

Same boxes, different flows. Sync-and-store unified APIs store a normalized copy of your customers' data. Call that platform **the vendor**: it sits between your server and the source API, the same position Unified.to occupies above.

A database sits on the vendor's side of the boundary, and reads are served from that copy rather than the source. The record you read is a copy of what was true at the last sync. The record you write lands in their database first and reaches the source later.

### [API path:](#api-path)

1. On a schedule the vendor sets, typically every 3 to 24 hours, it syncs data from the source API into its own database.
2. That stored copy is what serves your every read.
3. Your server requests data from the vendor API.
4. The vendor API reads from its database.
5. The database returns the cached copy.
6. The vendor API returns it to your server.

The read never reaches the source.

### [Native webhooks path:](#native-webhooks-path)

1. The source pushes the event into the vendor's database.
2. The vendor reads the change from that store.
3. The vendor delivers it to your server.

The store is in the path either way.

### [Write path:](#write-path)

1. Your server sends the update to the vendor API.
2. The vendor writes it to its own database.
3. The update reaches the source on the vendor's next sync.

Many sync-and-store vendors cache your update for up to 24 hours before it reaches the source. Some may push it through sooner.

Both patterns push where the source pushes and check on a schedule where it doesn't. Polling isn't the difference. Custody is: who holds your customers' records, and where they rest.

When a platform holds the copy, that copy is theirs to scope, reconcile, secure, and delete, and your customers' records sit in their infrastructure as a sub-processor. When it holds nothing, there is nothing to scope, nothing to reconcile, and nothing to delete.

Two questions separate the approaches:

**Does the event carry the records, or a pointer?** Poll-store-notify detects a change in the vendor's copy and tells you to call back for it. Poll-detect-deliver puts the changed records in the payload. Unified.to does the latter.

**Where does the data rest between detection and delivery?** Anything that polls into a store holds a copy. Unified.to holds none.

For the full comparison across all four generations of integration architecture, ETL, iPaaS, first-generation unified APIs, and real-time, see [Technology overview](https://unified.to/technology).