Measure the conversation, not the people in it

What you can actually measure

Search is the largest part of the catalogue. Keyword search, hashtag search, location and music search on the platforms that have them, plus the comment threads underneath any post you can identify and the trending feeds each platform publishes.

That covers most of what a listening product needs: how often a term appears, where it appears, how a thread reacts to something, which way volume is moving, and how that differs across 9 platforms rather than the one you happened to integrate first.

What comes back is the platform's own JSON, unrenamed. There is no sentiment score and no house schema, because a sentiment model is a decision about your product rather than ours, and a normalised schema quietly throws away the fields nobody thought to map. Full list in the API reference.

The limit, stated up front

Search results and comment threads hand back pages of people who are not the subject of your query. 209 of our 329 capabilities work that way, and our terms of service put a rule on them rather than leaving it to you.

Counting a page, ranking the posts in it, and measuring an audience in aggregate are fine. Keeping the individuals as a list of people is not. Neither is building something whose purpose is to profile, rank or score the people who show up in a response. The exact wording is in section 5 of the terms.

If you are building a listening dashboard, this costs you nothing — volume, share of conversation and trend lines are all aggregate by nature. If you were planning to turn commenters into a contact list, we are the wrong supplier and would rather say so on this page than after you have integrated.

We cannot inspect what you build and do not want the ability to, so this is a rule we enforce on complaint rather than a filter we apply. It is still worth knowing which side of it your product sits on.

Why this shape suits listening work

• A query is one call, not one call per result. Listening means polling the same terms on a schedule, so a per-record price is the one that hurts. A search here costs the same whether the page comes back full or empty.
• Repeat polling is cheap. A cached read costs nothing, so checking a quiet term every hour does not bill you every hour.
• Failed calls are free. A platform having a bad day does not show up on your invoice.
• One key, 9 platforms. Cross-platform share of voice is the whole point of listening, and it is the part that usually means nine integrations.
• Spending stops at your balance. A polling loop with a bug is the classic way to find out your vendor has no ceiling. At zero, requests are refused rather than billed.

One practical note: these routes are REST-only. They are deliberately not exposed to our MCP server, so an AI agent cannot run a search on its own initiative. Pulling pages of third parties should be something a developer chose to write. The reasoning is on the agents page.