Siftsy Analyst API
Siftsy reads the comments on your posts and scores how people reacted: how they feel, whether they stayed on topic, whether they agree with each other, and how the message and subject landed. You already see that in the dashboard for a post, a campaign, or any set of posts you pick. The Siftsy Analyst API brings that same picture into the workflows analysts already run, in the tools they already use.
It is built for the analyst who owns social and community reporting, in two directions:
- Import flagged content. Posts your listening tool, brand-safety team, or pipeline has flagged — or a public account’s recent posts — go into Siftsy programmatically, spending the same credits and running the same processing as Add New in the app. → Adding content
- Export key analyses and insights. Scores, mix bars, per-post analyses, selection analyses, and the reports teammates saved in the app come out as stable, paginated JSON that lands cleanly in Snowflake, BigQuery, Databricks, Redshift, or a BI tool such as Power BI, Tableau, or Looker. → BI sync
Every number the API returns is what Siftsy has already computed: it does not rescore posts, edit collections, or invent new scores, so an API result matches what a teammate sees in the dashboard. Comment routes return a sample of evidence behind an analysis, not a full thread — Siftsy is an analysis platform, not a comment exporter.
Create a key under Team Settings → API, then start here:
Create a key and make your first request.
Every endpoint, parameter, and example.
How it fits together
The Analyst API follows the same three steps you use in the product:
Select Content. Select posts the way you would in the dashboard: select posts by collection, content tag, filter by creator, platform, link, date, score, or sentiment, or pass specific post ids or links. That description is resolved when you call, and it caps at 1,000 posts. → Content selection
Comment Analysis is what the audience said. Each analysis has two sides: what was posted (the content, topics, and messages it was scored against) and how commenters responded (sentiment, relevance, consensus, content, and topic scores, plus the mix bars). You can narrow to a slice — a mix-bar bucket, keywords, usernames, and so on — or search in plain language. The numbers then describe only the matching comments, and scope tells you how big that slice is. → Analyses
Get comments. The analysis does not include comment bodies. Follow comments.path to get a sample of the comments behind the numbers. → Retrieving comments
Two things stay true throughout:
- The numbers match the dashboard. Scores, mix bars, filters, and search use the same paths the product uses, so an API result matches what a teammate sees when they click the same thing.
- Simple reads come back immediately. Heavier ones run as a job. A snapshot of stored scores returns in the same request. AI search, or a very large selection, is queued. Both use the same
Analysisobject with astatus, so your client can always: create, poll if you get a202, then sample the comments behind it.
Importing flagged content
The pipeline above reads posts that are already in your workspace. Getting them there is a separate, write path, and it is the only one the API has — built for feeding Siftsy the content another system has flagged for review:
Give a key the opt-in posts:write / accounts:write scopes and it can add posts by URL, or pull a public account’s recent posts filtered by date, engagement, and caption. It spends the same credits and runs the same processing as Add New in the app, so a teammate would get the identical result by pasting the links. You get back a content job that tells you what was accepted, skipped, or rejected, and how the accepted posts are progressing; once they are complete they are ordinary posts for the pipeline above. → Adding content
Nothing in the export pipeline depends on it: if teammates add content in the app, the API is read-only and the write scopes stay off.
Exporting to your warehouse
Everything the read routes return is designed to be loaded, not screen-scraped: cursor pagination, updated_since for incrementals, stable ids, one JSON shape per resource, and rate limits sized for a scheduled refresh rather than a realtime feed. A typical load pulls collections → posts → per-post metrics and analysis → saved reports, then samples comments only where a dashboard needs evidence. → BI sync, Rate limits
Guides
Choose posts with collections, tags, filters, or ids. The same selection lists posts and drives an analysis.
Creator side vs. audience side, the four kinds of analysis, narrowing vs. searching, and when a call becomes a job.
The saved per-post view, field by field, with a full example payload.
Sentiment, content, topic, relevance, and consensus on a 1–10 scale, and how the five mix buckets map to the dashboard. Consensus is about other commenters, not the post.
Every post filter, how matching works, and how filters work with paging.
Sample the comments behind an analysis, then narrow that sample by mix-bar bucket. Not a full-thread export.
Campaigns and groups as they appear in Siftsy, plus a sensible load order for a warehouse.
Team API keys and scopes, rate limits, and cursor pagination.
The write path: add posts by URL or a public account’s recent posts, with the same credits and processing as Add New. How the ingest runs and what a post goes through.
What to call when
Lists come back in pages of up to 100. If there are more, send the same filters with the cursor. See Pagination.
A full pass
Analyses walks this same sequence on a Dove brand + influencer campaign, with real responses.
Base URL
Send your key as Authorization: Bearer YOUR_API_KEY or X-Api-Key. See Authentication and Rate limits.