> ## Documentation Index
> Fetch the complete documentation index at: https://docs.embedreach.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Ongoing Data Sync

> Phase 4: Choose sync method and implement data flow

## Overview

Phase 4 is about implementing the ongoing flow of data to Reach. Once schemas are defined (Phase 3), you need to choose how to send data and keep it in sync.

## Choose Your Sync Method

Select the method (or combination of methods) that fits your infrastructure:

### Real-Time API

Send customer and transaction records to Reach API as events occur in your system.

**How it works:**

```javascript theme={null}
// When a new customer is created in your system
await fetch('https://api.embedreach.com/api/resources/contacts', {
  method: 'POST',
  headers: {
    'Authorization': `Bearer ${PARTNER_API_KEY}`,
    'X-Tenant-Id': tenantExternalId,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify(customerData),
});
```

**Best for:** Partners who want instant analytics and need real-time segmentation

**Pros:**

* Immediate attribution
* Real-time campaign targeting
* Fresh data for segmentation
* Users see changes instantly

**Cons:**

* Requires event hooks in your system
* More API calls (rate limiting considerations)
* Need error handling for each event

### Batch API

Send records to Reach API in scheduled batches (hourly, daily, etc.).

**How it works:**

```javascript theme={null}
// Daily batch sync of yesterday's transactions
await fetch('https://api.embedreach.com/api/resources/transactions/batch', {
  method: 'POST',
  headers: {
    'Authorization': `Bearer ${PARTNER_API_KEY}`,
    'X-Tenant-Id': tenantExternalId,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    resources: transactionsArray, // Array of transaction objects
  }),
});
```

**Best for:** Partners who prefer controlled sync windows or have high transaction volumes

**Pros:**

* Controlled sync windows
* Efficient for high volumes
* Easier error handling
* Can batch similar operations

**Cons:**

* Delayed attribution visibility
* Requires batch processing infrastructure
* Users don't see real-time updates

### Database Access

Grant Reach read-only access to a database view. Reach queries on a schedule to pull new records.

**How it works:**

1. Create read-only database views for customers, transactions, etc.
2. Provide Reach with database credentials (read-only user)
3. Reach queries on schedule (hourly, daily, etc.)
4. No code changes required in your application

**Best for:** Partners who prefer minimal integration work or need to backfill historical data quickly

**Pros:**

* Minimal integration effort
* Easy historical backfill
* Reach manages sync infrastructure
* No API rate limiting concerns

**Cons:**

* Security consideration (database access)
* Less real-time than API methods
* Requires database view creation
* Network connectivity requirements

### CSV Import

Provide Reach with CSV files of your data to be imported.

**How it works:**

1. Export data from your system as CSV
2. Send to Reach team via secure transfer
3. Reach imports and maps to schemas

**Best for:** One-time imports if batch processing or database access are not options

**Pros:**

* Simple for one-time needs
* No integration required
* Quick for historical backfill

**Cons:**

* Not suitable for ongoing sync
* Manual process
* Requires file preparation
* Not scalable

## Hybrid Approaches

Many partners use combinations:

<CardGroup cols={2}>
  <Card title="Hybrid Example 1" icon="database">
    **Database access** for initial historical load → **Real-time API** for ongoing syncs

    Best for: Quick historical backfill with real-time updates
  </Card>

  <Card title="Hybrid Example 2" icon="layer-group">
    **Real-time API** for transactions → **Batch API** for customer updates

    Best for: Immediate attribution with efficient customer syncs
  </Card>

  <Card title="Hybrid Example 3" icon="clock">
    **Batch API** for regular syncs → **Database access** for one-time historical backfill

    Best for: Ongoing batch syncs with easy historical import
  </Card>

  <Card title="Hybrid Example 4" icon="arrows-split-up-and-left">
    **Real-time API** for new records → **Batch API** for updates

    Best for: Fast new record creation with efficient bulk updates
  </Card>
</CardGroup>

<Tip>
  The key is **consistent data flow**—whether event-by-event or in regular batches. Choose what fits your infrastructure and commit to keeping Reach's data in sync with yours.
</Tip>

## Your Responsibilities

<Steps>
  <Step title="Provide sample data">
    Show Reach your existing data structure
  </Step>

  <Step title="Decide conversion event">
    What counts as a transaction for attribution
  </Step>

  <Step title="Choose sync method">
    Real-time API, batch API, database access, or hybrid
  </Step>

  <Step title="Implement sync service">
    If using API methods
  </Step>

  <Step title="Keep data flowing">
    As customers and transactions are created/updated
  </Step>
</Steps>

## Reach's Responsibilities

* Create custom schemas matching your data
* Map fields to attribution logic
* Provision custom API endpoints
* Handle schema evolution as needs change
* Query database on schedule (if using database access)

## Phase 4 Checklist

<Check>Sync method chosen based on infrastructure needs</Check>
<Check>Historical data backfilled</Check>
<Check>Ongoing sync implemented for new records</Check>
<Check>Update logic implemented for changed records</Check>
<Check>Transaction status changes synced</Check>
<Check>Error handling and retries in place</Check>
<Check>Monitoring and logging configured</Check>

## Next Steps

With data flowing to Reach, you're ready for product-specific setup.

<CardGroup cols={2}>
  <Card title="Phase 5: Channel Setup" icon="envelope" href="/onboarding/channel-setup">
    Configure email & SMS for Engage (if using)
  </Card>

  <Card title="Phase 8: Tracking" icon="code" href="/onboarding/tracking">
    Implement attribution snippet for Measure/Acquire (if using)
  </Card>
</CardGroup>