Migrate to Unified.to

Moving from another unified API is mostly a translation exercise. The categories, objects and CRUD operations you already use map onto Unified.to one to one, and your end users' third-party accounts stay where they are. What changes is how you identify a connection, how you page through lists, and how you receive changes.

Pick your current provider for a side-by-side guide covering authorization, API calls, pagination, webhooks and passthrough:

Moving from a provider that isn't listed, or from integrations you built in-house? The plan below still applies. Contact us and we'll help you map your current setup.

What changes

Most unified APIs share the same building blocks under different names. This table maps the common ones to Unified.to. Each provider guide has an exact mapping.

From a synced copy to real-time

Several unified APIs sync your customers' data into their own database on a schedule and serve your reads from that copy. Unified.to is a real-time pass-through API: every request goes to the source API and returns current data, and no end-customer data is stored at rest on our side.

In practice this means:

• There's no initial sync to wait for. A new connection can be read as soon as authorization finishes.
• Writes reach the source immediately, and the response reflects the source's result.
• You decide what to store. If your product needs a local copy, keep it in your own database and keep it current with webhooks. Webhooks deliver the changed records in the payload, not a pointer to fetch them.
• Reads cost source API calls. Read incrementally with updated_gte or webhooks rather than re-reading full lists on every request.

Migration plan

1. Inventory what you use

List the categories, objects, fields and write operations your code depends on, plus every webhook event you consume. Then check each integration's coverage on Supported integrations or in the integration's Feature Support tab in the dashboard. If something you rely on is missing, tell us before you start. Most gaps can be closed by adding the capability to the unified API.

2. Set up your workspace

1. Create an account at app.unified.to in the data region you need, and copy your API key and workspace ID from Settings > API Keys.
2. Activate the same integrations in your Production environment. Use your own OAuth app credentials for each vendor. If you already registered OAuth apps with vendors for your current provider, you can reuse them: add Unified.to's redirect URI to each app and enter the client ID and secret in the dashboard.
3. Request the scopes your code needs, and no more.

3. Move your connections

You have two options, and you can mix them per integration.

Re-authorize. Add the Authorization component to your app and ask each customer to reconnect. Pass your own user or account ID as external_xref (or state) so you can link the new connection ID to the right customer. Plenty of teams do this gradually: new customers go through Unified.to, and existing customers are prompted to reconnect when they next open the integrations page.

Import existing credentials. If you hold the credentials for a connection, such as OAuth tokens issued to your own OAuth app or an API key the customer gave you, create the connection directly with Create connection and your customer never has to reconnect. Some providers can export tokens on request, but only tokens issued to an OAuth app you own will keep refreshing after you switch.

curl -X POST https://api.unified.to/unified/connection \
  -H "Authorization: Bearer $UNIFIED_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "integration_type": "hubspot",
    "categories": ["crm"],
    "permissions": ["crm_contact_read", "crm_contact_write"],
    "external_xref": "customer_123",
    "auth": {
      "access_token": "…",
      "refresh_token": "…",
      "expiry_date": "2026-10-01T00:00:00Z"
    }
  }'

The response contains the new connection's id. Store it next to your customer record, where you currently keep the other provider's account token or ID.

4. Swap your API calls

Replace each call with its Unified.to equivalent. The URL pattern is https://api.unified.to/{category}/{connection_id}/{object}, so a single client covers every integration in a category. Our SDKs wrap the same endpoints if you prefer typed clients.

Update your field mapping from the other provider's model to the Unified.to model for each object; the API Reference lists every field. Where you read vendor-specific fields, use raw.

5. Replace sync and webhooks

Create a webhook for each connection and object you want to track, using created, updated or deleted events. Integrations without native webhooks get virtual webhooks, which check for changes on the interval you set. Webhooks can backfill historical data, so they can also replace an initial sync. Verify each payload's sig256 signature.

6. Run both, then cut over

Run Unified.to alongside your current provider for a subset of customers and compare results. Once you're confident, switch your feature flag, move the remaining customers, and delete the connections on your old provider so it stops holding their data.

Checklist

• Every object, field and write operation you use is supported for your integrations
• Integrations activated in Production with your own OAuth credentials and the right scopes
• Authorization component (or auth URL) live, with external_xref set to your customer ID
• Existing connections re-authorized or imported, and connection IDs stored
• API calls, pagination and filters translated
• Field mapping updated, including any raw fields
• Webhooks created, signatures verified, and old sync jobs retired
• Old provider's connections deleted after cut-over

Questions along the way? Join our Discord or email hello@unified.to.