modified_after

modified_after=2024-02-21T21:22:12.993Z

curl -X GET "https://api.bindbee.dev/api/hris/v1/employees?modified_after=2024-02-21T21:22:12.993Z" \
  -H "Authorization: Bearer <BINDBEE_API_KEY>" \
  -H "X-Connector-Token: <CONNECTOR_TOKEN>"

​

The delta sync pattern

1. On first run, pull everything with no modified_after, paging through with cursor.
2. Record the highest modified_at you saw across all pages, in UTC.
3. On the next run, pass that value as modified_after.
4. Upsert the returned records into your store, keyed on id.
5. Update your stored watermark and repeat.

params = {"page_size": 200}
if last_synced_at:
    params["modified_after"] = last_synced_at

while True:
    response = requests.get(
        "https://api.bindbee.dev/api/hris/v1/employees",
        params=params,
        headers=headers,
    ).json()

    for employee in response["items"]:
        upsert(employee)  # key on employee["id"]

    if not response["cursor"]:
        break
    params["cursor"] = response["cursor"]

​

Limits

• A resync makes everything look new. Records re-synced during a full resync get a fresh modified_at even when nothing changed upstream, so an incremental read can return the entire dataset. Expected behavior, not a bug.
• Always upsert, never insert blindly. The same record can appear in more than one window. Keying on id keeps this safe.
• Store the watermark in UTC and subtract a small buffer, for example one minute, before using it. That avoids dropping a record that landed between two pages of a long paginated run.
• modified_after is per model. An employee changing does not mark their employment or benefit records as modified, so filtering those separately misses related changes. Read them without the filter, or subscribe to data-change events for the model.

​

Related