You have a nightly job to write. A customer runs their workplace safety program on SafetyCulture, and you've been asked to pull their inspections, issues, assets, users and training progress into your own warehouse. The Data Feeds API looks like a gift: it exports a workplace operations account as flat data, and every one of its 39 operations is a GET. You expect to write one loop and reuse it.
The APIs.io catalog has just published a close reading of that API, and it says the loop won't be that simple.
Start with what ships. SafetyCulture scores 75.5 on the Kin Score, in the exemplar band, and 28.1 on Agent Readiness, in the agent-aware band. This API is one of 27 listed for the provider, with 418 operations between them. The record carries an OpenAPI contract, documentation, a getting-started guide, authentication and rate-limit records, a webhooks AsyncAPI, an llms.txt and six JSON Schemas. Auth is a bearer token. The rate limit uses a 60-second window, sends x-ratelimit-* headers and returns a 429 when you go over.
Now the part that matters for your sync. Only 13 of the 39 feeds declare a parameter that filters on when a record was modified, created or triggered. That means 26 feeds offer no declared way to fetch just what changed. Two more take only a date window, start_date and end_date, on both schedule_occurrences feeds. For the rest, you should plan on a full re-read every night, or on a different signal.
Paging is just as uneven. Twenty feeds declare next_page_token, such as /feed/action_fields and /scheduling/v1/feed/schedules. Eight declare offset only, such as /feed/schedules and the training course progress feed. Eleven declare no paging parameter at all, including /feed/inspections, /feed/issues and /feed/users. Those eleven are not necessarily unpaged. The feed metadata objects return next_page, and two of the three also return next_page_token. So a reliable client follows next_page and never builds the URL itself. The post calls that the good design hiding in here, and notes that a generated client working from parameters alone would miss it.
There are smaller snags you'd otherwise find at 2 a.m. The metadata's description tells you to send page_token in the request body, on an API that is all GETs, which the post says is worth correcting. The filter parameter is modified_after on most feeds but modifiedAfter on training, which uses camelCase across its multi-word parameters.
And there are two generations of the same data. /feed/schedules is summarised as "Data feed for Schedules (legacy)" and sits next to /scheduling/v1/feed/schedules. The same pairing holds for schedule assignees and occurrences, and /feed/action_fields has a twin at /tasks/v1/feed/action_fields, whose operation ID is FeedService_FeedActionFields2. No operation is marked deprecated, so only the summary tells you which to prefer, and only on some of them.
Here is the turn. The catalog doesn't only grade SafetyCulture; it points at its own record too. The provider record says api_count: 1, because the source is one published definition that the catalog split into 27 APIs. More awkwardly, the description and the page's base URL name api.safetyculture.io, while this contract's server is https://api.mitti.com, and its title and contact say Mitti. The record doesn't explain the difference. The post says reconciling those two values on the page is the catalog's job to do, and tells you to confirm the host in the developer docs before you integrate.
So you change your plan. You follow next_page instead of constructing URLs. You skip the legacy schedule paths. For the 26 feeds with no change filter, you stop pretending a delta exists: you either re-read them in full or pair them with SafetyCulture's webhooks, which are in the record. And before any of it, you check which host your customer's account actually talks to.
What you take away is a way to read this API: treat it as a bulk export with a mixed contract, not 39 copies of one pattern. Start at the Data Feeds API page, then verify the host.
Read the original: https://apis.io/2026/11/05/safetyculture-data-feeds-api-only-13-of-39-feeds-declare-a-change-filter/