Skip to main content

Publishing analytics API

Publishing Analytics API for Success Rates per Platform

Audience analytics answer how a post performed. Publishing analytics answer a different question: how much content actually went out, and how much failed. Wahdx Connection computes those numbers server-side from the publishing ledger, so the response stays small as volume grows. This page covers the endpoint, the difference between requests and attempts, and the fields worth alerting on.

The problem this solves

A publish button that returns success is not proof the post went live. A platform can accept the request and still fail the post, and a request can fan out to several accounts and thread items. Publishing analytics track volume and outcomes per platform, which turns publishing from a hopeful action into something with a success rate you can watch and alert on.

How the analytics endpoint works

GET /api/analytics/publishing returns aggregates for a date range. You can scope it with from and to timestamps, and the response returns rows plus a truncated flag. Aggregation runs in PostgreSQL, so the payload does not grow with publishing volume. The endpoint is available when the publishing ledger is enabled; in shadow or off mode it returns 404, and publishing behavior is unchanged.

A request and what it returns

The request is a single authenticated GET. Keep the API key server-side, and pass the date range your report needs.

GET /api/analytics/publishing?from=2026-08-01T00:00:00Z&to=2026-08-04T00:00:00Z
X-API-Key: <server-side key>

Requests versus attempts

One request can target several accounts and thread items, so the numbers split. request_count counts unique requests that targeted a platform, grouped by source (scheduled_post or direct_api). attempt_count counts provider-item attempts, with provider_accepted_count, published_count, failed_count, and skipped_count alongside it. Comparing the two shows whether a platform is rejecting at the request level or the item level.

Publishing analytics fields
FieldWhat it counts
request_countUnique requests targeting a platform, by source
attempt_countProvider-item attempts processed
provider_accepted_countAttempts the platform accepted
published_countAttempts that finished as published
failed_countAttempts that failed
skipped_countAttempts skipped by validation or limits

Fields worth alerting on

failed_count and skipped_count are the two numbers that move when something breaks, so a scheduled check that compares them against attempt_count gives you a publishing success rate per platform. provider_accepted_count against published_count separates a platform that accepted the post from one that finished it, which is where a slow platform shows up before it becomes a missing post.

Do not confuse it with audience analytics

Publishing analytics measure volume and outcome; audience analytics measure reach and engagement. They answer different questions and should stay in separate reports. Use publishing analytics to watch whether content goes out, and per-platform audience analytics to see how it performed once it did.

FAQ

Common questions about publishing analytics

What is the difference between request_count and attempt_count?

A request can fan out to many accounts and thread items. request_count counts unique requests targeting a platform, while attempt_count counts provider-item attempts.

Does publishing analytics need the ledger enabled?

Yes. The endpoint is available when the publishing ledger is enabled; otherwise it returns 404 and publishing behavior is unchanged.

Can publishing analytics replace status tracking?

No. Analytics summarizes volume and outcomes. Status tracking remains the way to monitor an individual post.

Which fields catch a failing platform fastest?

failed_count and skipped_count against attempt_count give a success rate per platform, and provider_accepted_count against published_count shows a platform that accepts posts but does not finish them.