Help Center

Data Connectors

Data Connectors Guide

This guide explains how data connectors work in Strand in plain language.

The Big Picture

In Strand, connectors can work with two different kinds of data:

  • Account data: company/account records (for example name, domain, owner, segment).
  • Event data: activity records over time (for example sign in, feature used, subscription changed).

A connector can support one type, both types, or only specific parts of each type.

Account Data (What it does)

Account sync creates or updates account records in Strand.

Common account-source connectors:

  • HubSpot
  • Stripe
  • Custom API (any REST endpoint)
  • BigQuery query sync
  • Snowflake query sync

How account data is processed

  1. Connector reads source data.
  2. Field mappings translate source columns/properties into Strand fields.
  3. Strand matches incoming rows to existing accounts.
  4. Strand creates new accounts or updates existing ones.

Whether new accounts are created depends on the connector setting:

  • Create new accounts when no match is found = on: Strand can create and update.
  • Create new accounts when no match is found = off: Strand only updates existing matched accounts.

Matching strategies

You can choose how Strand identifies the correct account:

  • Domain: match by companyDomain.
  • External ID: match by externalCustomerId.
  • Domain + External ID: allow either.

Strand fields vs custom fields

  • Some fields are built-in model fields (for example companyName, companyDomain, externalCustomerId, accountOwnerId).
  • Additional mapped fields are automatically created and saved as custom fields.

Tracked Fields in Settings

After fields are detected by sync, you can manage them in Settings -> Data Management (/app/settings/data-sync) under Tracked Fields.

Tracked Fields settings

Each field has two important controls:

  • Periodic: include or exclude that field from automatic periodic sync updates.
  • History: decide whether changes are kept as a timeline.

What this means in practice:

  • If Periodic is off, scheduled syncs do not update that field.
  • If History is on, each change is saved as a new historical record.
  • If History is off, Strand keeps the latest value without storing every change point.

Reserved and special fields

Strand has sync-only ingest fields that are used during sync logic and are not stored as normal custom fields.

  • accountOwnerEmail
    • Purpose: map the account owner by matching an organization member email.
    • Behavior: Strand looks up the member by email and links that person as account owner.
    • If no member matches, sync continues and owner assignment is skipped.
  • contactEmail
    • Purpose: create or update the primary synced contact for an account.
    • Behavior: creates/updates a Contact record with email, source: "sync", and isPrimary: true on create.
  • endUsers
    • Purpose: create or update additional synced contacts for an account.
    • Behavior: accepts a list of emails or a comma-separated string (for example a@company.com, b@company.com) and creates/updates Contact rows with source: "sync" and isPrimary: false on create.

Sync modes

  • Periodic sync: runs automatically on a schedule.
  • Manual sync: runs when a user clicks sync now.

Both modes support incremental sync when available.

Incremental sync

Some connectors support incremental sync, meaning Strand only fetches records that changed since the last successful sync instead of pulling everything again.

How it works:

  • After a successful sync, Strand saves the timestamp of when the sync started.
  • On the next run, only records modified after that timestamp are fetched.
  • If a sync fails (partially or fully), the timestamp is not advanced, so the next run retries the same window.

Connector support:

  • BigQuery / Snowflake: opt-in. Use the $LAST_SYNC_TIMESTAMP variable in your SQL query to filter by last sync time. Queries without this variable continue to do full sync.
  • HubSpot: automatic. When a previous successful sync exists, Strand filters by hs_lastmodifieddate so only recently changed companies are fetched.
  • Custom API: opt-in. Configure a timestamp query parameter (for example updated_since) and Strand passes the last sync time automatically.
  • Stripe: always full sync. Stripe’s API does not support filtering by last modified date.

Important:

  • For HubSpot, Custom API, and query-based connectors (BigQuery/Snowflake), changes to sync configuration can reset the incremental baseline. After major mapping/filter/query changes, expect the next sync to behave like a fresh run.

Event Data (What it does)

Event setup does not create/update account records.

Instead, it defines how Strand reads events and links events back to accounts when needed.

Common event-source connectors:

  • BigQuery
  • Snowflake
  • PostHog

How event data is processed

  1. You configure an event schema (time, event name, user id, account/domain source, properties).
  2. Strand queries events from the connector using that schema.
  3. Strand prepares event data in a common structure, making it usable for reporting and account-level insights

Event configuration chooses how to identify the account:

  • by domain, or
  • by external ID.

This must align with the identifier available in your event source.

Event schema special cases

  • For warehouses, you can map event properties with direct columns or expressions.
  • Expressions are useful for nested extraction and type conversion.
  • In BigQuery, event storage may be:
    • single table, or
    • one table/view per event.

Key Difference: Account vs Event Data

  • Account data changes account records in Strand.
  • Event data defines how Strand reads activity data and connects it to accounts.

They are complementary but independent.

Examples:

  • Use HubSpot/Stripe for accounts and BigQuery for events.
  • Use BigQuery for both accounts and events.
  • Use events only (if accounts are managed manually).

Practical Setup Guidance

  • Decide your source of truth for account records first.
  • Keep account matching strategy consistent across connectors.
  • Use clear camelCase Strand target fields in account mappings.
  • Use periodic sync for live systems and manual sync during setup/testing.
  • For events, verify account identifier mapping early (domain vs external ID) to avoid missing event-to-account links.