GET /v1/prompts/{id} — one tracked question, its rivals and its sources

A prompt is the unit of tracking, and this is the endpoint that opens one up. It returns the prompt's own metadata — its text, the topic it is filed under, the country it runs in — alongside its rates per platform, its change against the previous window, and two lists that are the real reason to call it.

The two lists

The first is competitors: the brands observed in the answers collected for this prompt, each with a rate. The second is sources: the external domains those answers cited, again each with a rate. Both are scoped to this prompt, which is what makes them worth a call of their own.

The analytics endpoint has competitor and source areas too, but those are workspace-wide aggregates. They answer "who shows up against us generally" and "which domains do the models trust in our category". This endpoint answers the much sharper version: on this exact question, in this exact window, who else was named and what did the model lean on. Those are the two facts you need before deciding whether the fix is a page of your own or a mention on somebody else's.

Because both lists come back inline, there is no second call to make. A pipeline that fetches a prompt and then queries the competitor area is asking a broader question and paying an extra round-trip for a worse answer.

Addressing a prompt by what it says

The path parameter takes an id or the prompt's exact text. The text form is a genuine convenience — it removes a search call when you already know the wording, which is the common case for anything driven off a spreadsheet or a config file.

It comes with two sharp edges. The match is exact, so a plural, a trailing space or a different capitalisation misses entirely and returns nothing rather than something approximate. And the text occupies a path segment, so it must be percent-encoded: a prompt containing a slash or a question mark will otherwise address a different route altogether, and the resulting failure looks like a missing prompt rather than a malformed request. If either bites, fall back to search, take the id, and use that.

Reading the rates

The same conventions apply here as everywhere else in the API. Rates carry their denominator, so you can see how much evidence a number rests on. Platforms that your plan does not track are marked as untracked rather than reported as zero, because they were never queried. And the delta carries a flag saying whether the movement cleared the significance test, so a report can distinguish a real decline from a week of noise.

Competitor rates deserve one extra sentence, because they are misread constantly. They use the same denominator as yours — successful runs naming the brand, over all successful runs — which means they are each brand's own mention rate rather than slices of a category. Nothing sums to one hundred percent, and a competitor sitting above you is mentioned more often, not ranked above you by anything Attensira computes. There is no rank here to read.

What comes next after a bad number

This endpoint tells you what happened. It does not tell you why, and it does not propose anything. When a prompt is losing and you want the reason, the agent is the surface for that: it can crawl the relevant pages, audit them the way a model sees them, and search the web, and it costs credits and takes time precisely because it is doing work rather than reading a table.

The right order is almost always the cheap call first. Look at the prompt, look at its sources, form a hypothesis, and only then spend an agent run on the part you genuinely cannot see from here.