---
title: "Analytics synced event"
method: POST
path: "analytics.synced"
tags: ["Webhook Events"]
---

# Analytics synced event

`POST analytics.synced` (webhook)

Fired once per connected account each time its analytics sync cycle completes
successfully. Poll-driven (roughly hourly per account), not real-time, and never
fired for a skipped or failed cycle.

A trigger, not a transport: the payload carries no metrics and no cursor. On
receipt, call `GET /v1/analytics/delta` with your own last `nextCursor` to read
every post whose analytics changed, across every account, in one paginated
stream instead of polling analytics once per account.

The feed holds back its most recent few seconds of writes, so a read issued the
instant this event lands often returns an empty page for that account. Poll again
with the same cursor rather than reading an empty page as "nothing changed".

High volume (roughly one delivery per connected account per hour). Subscribe to
it on a dedicated webhook endpoint: a subscription's consecutive-failure count is
shared across all of its events, so an outage while this event is flowing can
suppress the low-volume publishing events on the same subscription.

## Payload

- WebhookPayloadAnalyticsSynced — Webhook payload for `analytics.synced`. Fired once per connected account each time its analytics sync cycle completes successfully. Poll-driven (roughly hourly per account), not real-time, and never fired for a skipped or failed cycle. A TRIGGER, not a transport: it deliberately carries no metrics and no cursor. When it arrives, call `GET /v1/analytics/delta` with YOUR OWN last `nextCursor` to read what changed, across every account, in one paginated stream. The absent cursor is deliberate. The feed's ordering position is assigned inside the analytics store when the row is materialized, which normally has not happened yet at the moment this event fires, so a cursor minted here could sit ahead of the very rows the event announces and make you skip them. Your own `nextCursor` is always in the feed's own ordering and can never do that. Because of that same lag, a delta read issued the instant this event lands can legitimately come back empty. That is not "nothing changed": poll again with the same cursor you just used rather than treating the account as done. Subscribe to this event on a DEDICATED webhook endpoint. It is high volume (roughly one delivery per connected account per hour) and a subscription's consecutive-failure count is shared across all of its events, so an outage while this event is flowing can suppress the low-volume publishing events that share the same subscription.
  - `id` string, required — Stable webhook event ID
  - `event` 'analytics.synced', required
  - `account` object, required
    - `accountId` string, required — The account's unique identifier (same as used in /v1/accounts/{accountId})
    - `profileId` string, required — The profile this account belongs to
    - `platform` string, required
    - `username` string, required
  - `sync` object, required — Summary of the analytics sync cycle that just completed.
    - `syncedAt` string, date-time, required — When the cycle COMPLETED. Not a join key for the delta feed: the rows a cycle produces carry a `syncedAt` stamped when the cycle STARTED, which is measured at around one second earlier at the median and up to a couple of minutes earlier in the tail. Correlate on `account.accountId`.
    - `postsUpdated` integer, required — Post records created or modified by this cycle. Not the number of delta feed rows the cycle produced, which the syncer does not report, so a cycle with a non-zero `postsUpdated` can still yield an empty delta page.
  - `timestamp` string, date-time, required — UTC time at which Zernio generated this event (set once when the event payload is built, before delivery is queued).

## Acknowledgement `200`

Webhook received successfully

---

[API](https://skmtc.dev/zernio/apis/zernio-api.md) · [All operations](https://skmtc.dev/zernio/apis/zernio-api/llms.txt) · [OpenAPI document](https://skmtc-service-production.skmtc.workers.dev/v1/apis/zernio/zernio-api/revisions/08611567febf/schema)