How to Use Postman with Unified.to

January 6, 2026

Postman is the fastest way to explore, understand, and debug the Unified.to API before you write application code.

Unified.to provides an official Postman workspace and collection that mirrors the real production API: same endpoints, same auth model, same normalized data. This makes Postman ideal for learning the API surface, validating integrations, and troubleshooting requests.

This guide explains how to use Postman correctly with Unified.to, what you need to configure, and where Postman fits (and doesn't fit) in your development workflow.

When Postman is the right tool

Postman works best for:

• Exploring Unified's API categories and objects
• Verifying authentication and permissions
• Testing read-only requests against real integrations
• Debugging request payloads, parameters, and responses
• Sharing reproducible API examples with teammates

Postman is not intended for production workloads, automation, or customer-facing usage. Those belong in your backend using SDKs or raw REST.

Step 1: Import the Unified.to Postman collection

Unified maintains an official Postman workspace containing pre-configured requests for all API categories.

You can access it in two ways:

• Open the Unified.to Postman workspace directly
• Or download and import a collection.json file (either the full API or category-specific collections like CRM, Calendar, HRIS, etc.)

Each collection mirrors the REST API exactly—no Postman-specific abstractions.

Step 2: Create a Postman environment

Unified does not ship a pre-configured Postman environment. You'll need to create one manually.

At minimum, define the following environment variables:

Optional (but useful):

• limit – default page size (e.g. 25)
• cursor or offset – for pagination

Regions

Unified operates fully isolated regions. Your base_url should match where your workspace is provisioned:

• US: https://api.unified.to
• EU: https://api-eu.unified.to
• AU: https://api-au.unified.to

Step 3: How authentication works in Postman

Authentication is handled via a standard HTTP header on every request:

Authorization: Bearer {{api_key}}

Key points:

• Auth is defined at the collection level, not per request
• No OAuth flow runs inside Postman
• No pre-request scripts are required
• The API key must belong to the workspace that owns the connection_id

If authentication fails, Unified returns a standard JSON error with a 401 or 403 status.

Step 4: Understand the role of connection_id

Every Unified request is scoped to a customer connection.

A connection_id represents a single authorized third-party account (for example, one Salesforce org or one Google Drive account).

Postman does not create connections. You must:

1. Authorize a connection using Unified's dashboard or embedded auth
2. Copy the resulting connection_id
3. Paste it into your Postman environment

Once set, the same request works across all supported vendors in that category.

Step 5: Make your first request (recommended example)

A good first request is a simple, read-only endpoint that exists across many integrations.

Example: List CRM contacts

GET {{base_url}}/crm/{{connection_id}}/contact?limit=25

Why this endpoint:

• Read-only
• Minimal permissions
• Supported across most CRMs
• Returns normalized data
• Works reliably for first-time testing

High-level response shape

{
  "data": [
    {
      "id": "string",
      "name": "string",
      "emails": [],
      "phones": [],
      "created_at": "timestamp",
      "updated_at": "timestamp"
    }
  ],
  "next_cursor": "string | null"
}

Unified normalizes fields across vendors, so the response shape is consistent whether the source is Salesforce, HubSpot, or Zoho.

Step 6: Pagination behavior

Unified uses explicit pagination. Postman does not auto-paginate.

Common patterns:

• limit – number of records per request
• cursor or offset – provided in the response

To fetch additional pages:

1. Copy next_cursor from the response
2. Set it as an environment variable
3. Re-run the request

Each page counts as a separate API call.

Step 7: Common errors you'll see in Postman

All errors return structured JSON with a message and error code.

Postman vs OpenAPI import

Unified supports both approaches:

Use the Postman collection when:

• You want ready-to-run examples
• You're exploring the API for the first time
• You want curated, validated requests

Import OpenAPI when:

• You want to generate your own Postman structure
• You're testing specific subsets of the API
• You're building mocks or documentation

For most developers, the official Postman collection is the fastest starting point.

What Postman should not be used for

Postman is not suitable for:

• Production API traffic
• Background jobs or syncs
• Customer-initiated requests
• Webhooks or streaming
• Load testing

Once you understand the API, move to:

• Unified SDKs (TypeScript, Python, Go, etc.)
• Or raw REST calls from your backend

Summary

Postman is the quickest way to get hands-on with Unified.to:

• One API key
• One connection ID
• One request works across dozens of integrations

Use Postman to explore, debug, and validate. When you're ready to ship, move the same requests into your backend—unchanged.

Resources

• Unified Postman workspace
• Unified API docs
• Start your 30-day free trial
• Book a demo