Data freshness

Data freshness

The Partner API v2 offers best-effort consistency, not strict real-time guarantees. This section explains what "live" means and how to sync efficiently.

The lastUpdatedUtc field

Most resources carry a lastUpdatedUtc timestamp — a full ISO-8601 UTC instant (e.g. 2026-05-29T12:48:08Z). It is your freshness signal: it advances when the underlying data changes.

• On Bolagsanalys /data, it is the figure's own update time (a precise instant — v2 does not truncate it to a date the way v1 did).
• On Fastighetsbenchmark Comp resources, it is derived as the most recent of the row's audit/refresh/freeze timestamps, so it moves forward whenever the Comp is refreshed from its source or re-frozen.

The recalculation queue (why data can lag)

Fastighetsbenchmark derives many values (aggregates, formula-calculated parameters) asynchronously. When something changes — you create a Samling (The Comp Composite & clone lineage), or an upstream source is refreshed — Sedis enqueues a recalculation that runs in the background.

Practically:

• A POST /samlingar returns 201 immediately, but the Samling's derived values may not be fully computed for a few seconds to minutes while the recalc cascade runs.
• A figure you expect may briefly lag real-time during heavy recalculation.

This is normal and expected. Poll lastUpdatedUtc (or just re-fetch) if you need to observe a freshly-triggered recalc landing.

Conditional requests save work

Because lastUpdatedUtc drives the ETag, conditional requests are the efficient way to sync:

# You stored this ETag from a previous sync
curl -i -H "X-Api-Key: $SEDIS_API_KEY" \
  -H 'If-None-Match: W/"lastUpdated-1735689600"' \
  "https://api.sedis.se/v2/fastighetsbenchmark/property-units?sedisId=PU-1"
# → 304 Not Modified  (nothing changed since you last fetched — no body, no transfer)

• A 304 means nothing changed — skip it, no bandwidth used.
• A 200 with a new ETag means the data moved; store the new ETag for next time.
• List ETags incorporate max(lastUpdatedUtc) and totalCount, so any addition or change to the result set invalidates them.

See Query conventions for the ETag mechanics and Rate limits for why this also helps your rate budget.

Recommended sync pattern for BI

1. Page through with a steady pageSize and ?count=false on /comp-data.
2. Store the ETag per query.
3. On the next sync, send If-None-Match; act only on 200s.
4. Track lastUpdatedUtc per row if you need change-detection at row level.