Skip to main content
The Nordic Financial News API supports a polling pattern for keeping a local data mirror in sync. Use the updated_after parameter on the /articles, /stories, and /calendar_events endpoints to fetch only records that changed since your last sync. An updated_after request is a resumable walk, not a snapshot. Results are ordered by updated_at ascending and cursor-paginated, so you must follow the cursor to the end before you record a new watermark.
A response is capped at limit (default 25, max 100). Advancing your stored timestamp before draining every page skips the remainder permanently.

How to poll for updates

1

Request records changed since your watermark

Pass updated_after with your stored watermark, and request updated_at so you can track your position from the data itself:
Results come back ordered by updated_at ascending, cursor-paginated.
2

Drain the cursor

Follow pagination.next_cursor, resending the same updated_after value alongside it, until next_cursor is null.
3

Track the highest updated_at you saw

As you process records, keep the maximum updated_at across every record drained in this walk. That value, not your clock, is your new high-water mark.
4

Commit the watermark with a one-minute overlap

Once the walk finishes, store the highest updated_at you saw minus a one-minute overlap as your new watermark. Reconcile the re-delivered records by id on the next poll.
The overlap is not optional. A record’s updated_at is stamped when the write happens, but the record only becomes visible when that write commits a moment later. Without the overlap, a record stamped just below your watermark that commits just after your walk is skipped by this poll and excluded by every later one, because the filter is a strict updated_at > watermark. Re-reading a minute of changes is cheap. Losing a record is permanent.
The Link header’s rel="next" URL preserves your full query string, including updated_after and any filters, so following it directly is the safest way to page.

Polling example

Re-delivery at the overlap margin is expected. Reconcile by id so repeated records update in place rather than duplicating.
updated_after accepts YYYY-MM-DD or YYYY-MM-DDTHH:MM:SSZ (optionally with milliseconds). Python’s datetime.isoformat() emits microseconds and a +00:00 offset, both of which are rejected with a 400. Use strftime("%Y-%m-%dT%H:%M:%SZ") as shown above.

How the updated_after parameter works

When updated_after is set:
  • Results are ordered by updated_at ascending, with id as a tiebreaker, so a partially drained walk can be resumed from its cursor
  • Results are cursor-paginated and capped at limit. Follow pagination.next_cursor until it is null
  • The filter is strict (updated_at > your watermark), so a record is not redelivered unless it changed again. This is why the one-minute overlap matters: it is what makes redelivery happen at the margin
  • The walk covers the full served dataset. A first sync from an old watermark returns history, not just recent records
  • ETag caching is disabled since the results are time-sensitive
  • The response includes both newly created and recently modified records
List payloads for articles, stories, and calendar events include updated_at. Request it explicitly when using field projection.

Removals are not signalled

A record that is withdrawn, hidden, or otherwise falls out of visibility simply stops appearing in walks. There is no tombstone and no deletion event. A mirror built this way is append-and-update, not an exact replica of the served dataset.

Calendar events

Calendar events sync the same way, at /api/v1/calendar_events, with two behaviors specific to the endpoint. Sync walks include past events. The endpoint’s default listing returns upcoming events only, floored at today by the issuer’s local date. Passing updated_after lifts that floor, so a sync walk covers the full served dataset. This matters because the most common calendar change lands on a past event: every event flips from scheduled to published roughly two days after its date. Corrections and reschedules to past events reach mirrors the same way.
Lifting the floor is forward-looking. Updates to past events that occurred before your currently stored watermark are not replayed. To backfill that history, reset your watermark to an old timestamp and run a fresh sync, which returns full history exactly as it does for articles and stories.
Cancelled events are excluded. List endpoints return scheduled and published events and exclude cancelled by default, so a scheduled → cancelled transition never surfaces in a default sync walk. To track cancellations, poll separately with status=cancelled, or use cancellation alerts.
A company-level edit such as a rename, visibility change, or listing change re-stamps all of that company’s content. One edit can push a company’s entire kept event history into a single sync delta. It drains normally via the cursor, and a suddenly large delta is expected rather than a fault.

Plan coverage

On the free plan, sync is a sliding window rather than a full mirror. Only articles from preview sources are served, within a recency window and up to a count cap, so records leave the window without any signal as newer ones arrive. Building a complete local mirror requires a paid plan. The current free-plan source list, recency window, and caps are listed on the pricing page.
Use the fields parameter to request only the fields you need, reducing bandwidth and response time. A 30-60 second polling interval works well for most use cases.

Migrating an existing integration

Ordering changed: updated_after results were previously sorted by published_at descending and are now sorted by updated_at ascending. If your integration assumed newest-first, update it.If you polled updated_after before this change, your local copy may have gaps. Re-sync your history once using the drain loop above.
Last modified on August 5, 2026