Working with Custom & Original Fields

Updated: September 27, 2026

When working with integrations, you often need control over which fields to receive or send. This guide explains how to work with both standard and custom fields. The same fields options apply to webhook payloads, for native and virtual webhooks.

Choosing how to access vendor-specific data

The unified API reads and writes the fields in Unified.to's data model. For data outside that model, use these options in order:

1. Metadata API. Where an integration supports it, vendor custom fields are available through the Metadata API (see Metadata). Check the integration's Feature Support tab.
2. Raw fields. Read the vendor's original data and write vendor-specific values using raw, as described below.
3. Passthrough. For vendor endpoints that aren't part of the unified API, use Passthrough (see Passthrough). Contact us before building on Passthrough, since most gaps can be closed by adding the capability to the unified API.

The outer limit is the vendor's own API: if the vendor doesn't support a write, no route through Unified.to will.

Requesting Specific Fields

By default, API calls return all available fields for an object. However, you can optimize your requests by specifying only the fields you need using the fields parameter:

Some upstream APIs also return slow fields that require additional API calls per record (for example, Greenhouse application offers or raw.offers). These can be excluded or included by default at the workspace level and overridden per request using fields. For details, see Slow fields.

GET /crm/{connection_id}/contact?fields=id,name,emails

Accessing Original Data (Raw Fields)

Reading Original Data

Sometimes you need access to the original, unmodified data from an integration (for example, to access platform-specific fields). To receive this data:

1. Include raw in your fields parameter
2. The response will include a raw object containing the original data from the source

GET /crm/{connection_id}/contact?fields=id,name,emails,raw

Writing Original Data

When creating or updating records, you can include integration-specific data that isn't part of our unified data model:

{
    "name": "John Doe",
    "raw": {
        "custom_integration_field": "value"
    }
}

Accessing the original ID of the object

Usually, Unified.to will return the object's ID in the id field.

But sometimes, Unified.to is required to transform that original ID with additional information. If you require the original object's ID (for example, using our Passthrough API), it will be available in the raw.__id field.

Working with Custom Original Fields

Some CRM platforms (like HubSpot and Salesforce) require specific fields to be explicitly included in the API call i.e., they won't be returned if you only added raw to the request parameters. If your app requires specific fields in this way ("custom fields"):

1. Include raw in your fields parameter
2. Add the specific custom fields you need with the raw. prefix

For example, to request custom fields named leadFunnelStage and customerSegment:

GET /crm/{connection_id}/contact?fields=id,name,raw,raw.leadFunnelStage,raw.customerSegment