> ## Documentation index
> Fetch the complete documentation index at: https://docs.prescientai.com/llms.txt
> Use this file to discover all available pages before exploring further. Add `.md` to any page URL to get that page as Markdown.

# Sync only the rows that changed

> How to use the processDate argument of the Prescient GraphQL API so that a daily job copies new and updated rows and not the full history.

To keep a copy of your data current, set the `processDate` argument. The query then leaves out each row that was not created or updated on or after that date. Both [`modeledMetrics`](https://docs.prescientai.com/api/queries/modeled-metrics) and [`reportedMetrics`](https://docs.prescientai.com/api/queries/reported-metrics) have this argument.

## Why use `processDate`?

A row can change after the first time you read it. A date range alone makes you read each row of the range again to find the changes. With `processDate`, the response has only the new rows and the changed rows, so the job reads less data.

The schema recommends `processDate` in each integration, and one pull of updates each day.

## How do you set up a daily sync?

1. Run a first pull with a date range that covers the history you need, and no `processDate`. See [Pull modeled metrics for a date range](https://docs.prescientai.com/api/pull-modeled-metrics).

2. Record the date on which the pull started.

3. In each later run, set `processDate` to the date of the last run that finished. Set `startDate` to the start of the history that you keep, because a changed row can have an old `reportedDate`.

   ```json title="Variables"
   {
     "startDate": "2025-01-01",
     "endDate": "2026-01-31",
     "processDate": "2026-01-30",
     "after": null
   }
   ```

4. Follow the cursor until `hasNextPage` is `false`. See [Pagination](https://docs.prescientai.com/api/pagination).

5. Write each row over the row in your copy that has the same key. Then record the date of this run.

## Which fields identify a row?

The API does not return a row ID, and the schema does not define a unique key for a row. Before you build the sync, choose the fields that identify a row in your copy and test them on your data.

- For `modeledMetrics`, start with `reportedDate`, `sourceChannelName`, `sourceCampaignId`, `target`, `metricName`, and `targetChannelName`.
- For `reportedMetrics`, start with `reportedDate`, `channelName`, and `campaignId`.

Each row also has a `processDate` field, which is the date the row was created or last updated.

## What should you know about the dates?

- `processDate` is a date, not a time. A row that changed on that date is in the response, so a run can return a row that the last run returned. Write over the row, and do not add it a second time.
- If you leave out `startDate`, the range starts 30 days before today. A changed row with an older `reportedDate` is then not in the response.