/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 acceptupdated_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 onupdated_at with cursor pagination to handle multiple pages.
Documents
News
Events
Events requirepagination=cursor to use cursor pagination:
Pagination
All three endpoints return apagination object with next_link when there are more results. Follow next_link until it’s null to fetch all pages.
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.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
GitHub Actions
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 thegte boundary.
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:
Scoping to specific companies
If you only care about a subset of companies, addcompany_domain to scope results:
Tips
- Upsert, don’t insert. Use
id(documents, news) orevent_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.