Overview

The modified_after query parameter lets you fetch only the records that have changed since a given point in time, based on Merge's modified_at timestamp. It's the recommended way to run incremental syncs after your initial pull from Merge.

Note: All Merge timestamps follow standard ISO 8601 format in the UTC timezone.

What is the modified_at field?

The modified_at value is the date the data object was last modified in Merge's database. This value will likely be different than the date the object was last updated in the third-party system.

How does modified_at get updated?

The modified_at field is updated when there are changes to Common Model fields. This includes all properties of the standard Common Model, Field Mappings, and Remote Field Classes, but it does not include fields found in Remote Data.

How do I use the modified_after and modified_before filters?

The modified_at field can be leveraged to query data modified before or after a specific date. For example, to query data modified after 01/01/2023, use the modified_after timestamp filter — it returns records whose modified_at value is after that date. The modified_before filter does the opposite and returns records modified before a given date.

The modified_after query parameter is most commonly used to efficiently sync data after the initial pull from Merge. If you store the timestamp of when you last started pulling data for a given Linked Account, you can pass it to modified_after to pull only the updates since your last sync.

When should I not use the modified_after filter?

• Avoid combining modified_after with the expand parameter — modified_after does not take into account expanded objects. For example, if you query GET /employees with both parameters and a Group's name is updated, the Employees within that modified Group will not be returned (unless the Employee record itself was also modified). See Using the expand parameter for more context.

  GET /employees?expand=groups&modified_after=2025-01-01T00:00:00Z

• Avoid combining modified_after with other filter parameters such as employment_status — doing so can lead to loss of data. For example, filtering for Active employees modified after a certain time could cause an employee whose status changed to Inactive after that time to be excluded from your results.

Who should I contact for help?

If you have questions about incremental syncing or behavior of the modified_after parameter, please reach out to us at [email protected].