Skip to main content
The Sacra API supports time-windowed queries across /documents, /news/company, and /events, so you can poll for changes on a schedule instead of re-fetching everything. This guide walks through setting up a daily sync that fetches only what’s changed in the last 24 hours.

How sync works

All three endpoints accept updated_at_gte and updated_at_lte query parameters to filter results to a time window. Combine these with cursor pagination to walk through all changes since your last sync.
Domain-less news queries (no company_domain parameter) require a date window of 14 days or less. A daily 24-hour window is well within this limit.

Query structure

Each sync request uses the same pattern: a 24-hour window on updated_at with cursor pagination to handle multiple pages.

Documents

News

Events

Events require pagination=cursor to use cursor pagination:

Pagination

All three endpoints return a pagination object with next_link when there are more results. Follow next_link until it’s null to fetch all pages.
Use the next_link URL directly — it includes all your original query parameters plus the cursor.

Complete sync script

This Node.js script polls all three endpoints with a 24-hour window and collects every changed record. You can wire the results into your database, search index, or file system.
Run it manually to verify:
Expected output:

Schedule with cron

Once the script works, schedule it to run daily. A common choice is once per day at midnight UTC.

Linux/macOS crontab

Add:

GitHub Actions

Store your API key in environment variables or a secret manager. Never hardcode it in the script or commit it to source control.

Tracking sync state

The script above uses a rolling 24-hour window, which is simple but may miss items if a sync run is skipped or delayed. For more robust syncing, persist the timestamp of your last successful sync and use that as the gte boundary.
This way, if a run fails midway, the next run retries from the same starting point.
If you’re running on GitHub Actions or a stateless environment, store the checkpoint in your database or an S3 object instead of a local file.

Using created_at vs updated_at

The endpoints support both created_at and updated_at filters. Which you use depends on what you’re trying to capture:
Use updated_at for sync workflows. It catches both new and modified records in a single pass.

Scoping to specific companies

If you only care about a subset of companies, add company_domain to scope results:
This works for all three endpoints. Company-scoped queries don’t have the 14-day window limit that domain-less news queries have.

Tips

  • Upsert, don’t insert. Use id (documents, news) or event_id (events) as the primary key and upsert on each sync. An item updated twice in 24 hours will appear once in the response with its latest state.
  • Overlap your windows slightly. If you’re using a fixed 24-hour window rather than checkpoint-based sync, consider a small overlap (e.g., 25 hours) to avoid missing items updated right at the boundary.
  • Handle empty pages. Some days may have no changes for a given endpoint. The response will have an empty array and total_items: 0 — this is normal.
  • Log what you sync. The script above logs each synced item. In production, log the counts and any errors so you can audit sync health.
  • Rate limiting. The Sacra API has rate limits. If you’re syncing large volumes, add a small delay between paginated requests. For daily syncs with a 24-hour window, you’re unlikely to hit limits.
  • See the changelog. For full details on the sync-related API additions, see Content Synchronization Updates.