BI sync

The export side of the Siftsy Analyst API. A typical full sync into a warehouse or BI model:

1

Collections dimension

GET /collections — build the collection table. Campaigns include nested groups; posts join via collectionIds.

2

Posts fact table

GET /posts?limit=100 and follow nextCursor. Default status is complete. Use status=all only if you need pending/archived/unreachable rows.

3

Per-post metrics and analysis

GET /posts/{id}/metrics — daily score rollups and mix buckets. Skip or retry 404 until scoring completes. GET /posts/{id}/analysis — content + comment analysis. Skip a per-post comments crawl. If you need evidence for a specific analysis, sample it with GET /posts/{id}/analysis/comments?source=notables — not a full-thread export.

4

Campaign analyses

GET /analyses?kind=report — list persisted campaign reports (up to 1,000 posts each). GET /analyses/{id} — the report. Comment bodies are not included. GET /analyses/{id}/comments?source=notables — a sample of comments behind that analysis, not the full sections.

5

Rollups per collection or tag (optional)

POST /analyses with selection.collectionId or selection.posts.tag — one aggregate per campaign / tag, computed from stored scores. Selections of ≤ 100 posts return 201 ready inline; larger ones return 202 and are polled at GET /analyses/{id}. Recreate on each sync — analyses expire after 7 days. See Analyses.

Refresh schedule

A full sync of a 500-post workspace is about 1,070 requests and 15 MB. Budgets fit eight of them a day (the Power BI Pro scheduler maximum), or — cheaper — one full sync plus hourly incremental runs (GET /posts?updated_since=<last run>, then metrics and analysis only for the posts returned). Recreate rollups on one sync a day, not every run. Run the refresh queries sequentially or at most two in parallel; the per-minute caps are sized so a sequential loop never sees a 429. See Rate limits for the worked budget.

Data classification

Comment text and usernames are customer data. addedByEmail identifies the teammate who added the post (for automation-added posts, the teammate who set up the automation); addedVia is api for posts added through the content routes, automation for posts a Siftsy Automation pulled in on a schedule, and dashboard otherwise. automation (null or { addedById, ids, lastRefreshAt, refreshCount }) lists every automation that has added or refreshed the post, so a manually added post that an automation keeps refreshed shows addedVia: dashboard with a non-empty automation.ids. Recipients are responsible for retention and downstream sharing.

Demo or admin-uploaded posts may appear with isDemo: true and do not imply billing usage.