For the complete documentation index, see llms.txt. Every page on this site is also served as Markdown: append `.md` to any URL, or send `Accept: text/markdown`.
Attensira Logo
Attensira

REST API endpoint

DELETE /v1/prompts/{prompt} — stop tracking, and lose the history

Permanently stops tracking a prompt and frees its slot. The historical data goes with it, and there is no undo.

Karl-Gustav KallasmaaKarl-Gustav Kallasmaa, Founder & CEOLast updated
DELETE /v1/prompts/{prompt}Needs write scopeSpends no creditsDestructiveMCP tool: remove_prompt

The request

Paste this and change the key. Every endpoint takes a bearer key and none takes a workspace id — the key names the workspace.

curl -X DELETE https://api.attensira.com/v1/prompts/prm_8f21 \
  -H "Authorization: Bearer atn_live_<your key>"

Parameters

Every parameter the published reference documents, and nothing it does not.

NameInTypeDefaultNotes
prompt*pathstring—A prompt id. Unlike the read endpoint, this one does not accept prompt text — deletion by fuzzy identity would be a bad idea.

The response (200)

Abbreviated, never invented — this is the shape the published reference documents.

{ "id": "prm_8f21", "removed": true }

What goes wrong, and what it means

The condition on the left, the correct reading of it on the right.

You deleted the wrong prompt
There is no undo and no restore. The history went with the prompt, which is why the documented order is to fetch the prompt first and confirm it is the one you mean.
A dashboard chart now ends abruptly
That is expected. No new readings are collected after removal, so any trend line for that prompt stops on the day you removed it.
A subsequent add of the same text creates a new prompt
It does, with a new id and no history. Re-adding is not undeleting, and it starts collecting from the next run like any new prompt.

What this endpoint cannot tell you

The limits are part of the answer, not a disclaimer under it.

  • It cannot be reversed. The prompt's collected history is removed with it, so anything you want to keep has to be fetched before the call rather than recovered after it.
  • Re-adding the same text does not restore anything. It creates a new prompt with a new id that begins collecting from the next run, so the gap in the series is permanent.

This is a small endpoint with a large consequence. It takes a prompt id, stops tracking that prompt, frees the slot it occupied against your plan's ceiling, and removes what was collected for it. The response is two fields and there is no second step.

Why it takes an id and nothing else

The read endpoint will accept a prompt's exact text as a convenience, and this one deliberately will not. Fuzzy identity is fine for a lookup and unacceptable for a delete: a near-miss on a read returns nothing, while a near-miss on a delete would remove something you did not mean. So the identifier here is an id, and getting one means a call to search or to the read endpoint first.

That extra call is the feature. The documented order is to confirm the prompt before removing it, and the confirmation is free.

What "cannot be undone" actually covers

Three separate things go away and it is worth naming them individually.

The tracking stops, which is the part you asked for. The slot is freed, which is usually why you asked for it — plans cap how many prompts a workspace holds, and this is the only way to make room. And the history goes, which is the part people do not expect. Anything you wanted from the prompt's record has to be fetched before the call; afterwards there is nothing left to fetch.

Re-adding the same wording later does not walk any of that back. It creates a new prompt with a new id, which begins collecting from the next run like any other new prompt. The gap in the series between the delete and the re-add is permanent, and so is everything before it.

What it does to your charts

Any trend line for that prompt ends on the day you remove it. That is not a bug in whatever is drawing the chart, and it is worth saying out loud before a bulk cleanup: a workspace-level number computed across prompts will move when the set of prompts changes, and the movement is an artefact of the cleanup rather than anything about your visibility.

If you are removing several prompts, the honest thing to do afterwards is to note the date somewhere, because six weeks later a step in a workspace chart is very hard to distinguish from a real change.

A safer cleanup routine

The cheap way to decide what to remove is to rank before you delete. The prompt area of the analytics endpoint, called with a long window, orders your prompts by how they are doing and costs nothing. Prompts with almost no readings, prompts on topics you no longer sell into, and duplicates that crept in through separate imports are the usual candidates.

Fetch each one you intend to remove, keep whatever you want from the record, then delete by id. Three calls per prompt sounds heavy and is in fact the correct amount of ceremony for an irreversible action against a paid resource.

The other reason to be careful

The write scope covers this endpoint, and so does an assistant connected over MCP with write access. An API key or an OAuth connection that can delete prompts is a workspace credential rather than a read token, and the practical consequence is that a badly-scoped automation can quietly cost you a quarter of history. Mint read-only keys wherever a caller only reads, and keep the ability to delete on the credentials that genuinely need it.

A note on bulk removals

Removing prompts in bulk is where this endpoint does the most damage, because the individual decisions get made quickly and the consequences are collective. A workspace figure computed across prompts will shift the moment the set of prompts changes, and six weeks later that shift is indistinguishable from a real movement in visibility. If you are clearing out more than a handful, do it in one sitting rather than over a fortnight, record the date, and treat every chart that spans it as two separate series rather than one.

Questions people ask

Can I delete a prompt by its text?
No. The read endpoint accepts text as a convenience, but deletion takes an id only. Identify the prompt with search or the read endpoint first.
Does deleting refund credits?
No. The endpoint spends nothing and returns nothing. What it frees is a prompt slot against your plan's ceiling.
Can I get the history back?
No. Fetch it with GET /v1/prompts/{prompt} before you delete if you want to keep it — after the call there is nothing to fetch.
What is the safest way to clear out unused prompts?
Rank them first. The prompt area of the analytics endpoint with a long window shows which prompts have accumulated nothing worth keeping, and it costs nothing to look.
What is the MCP equivalent?
The remove_prompt tool, which is equally destructive, needs the write scope and takes a prompt id rather than free text.

Sources

Every factual statement above, with the page it came from and the date that page was read.

  1. The Attensira API reference states that deleting a prompt permanently stops tracking it, that its historical data goes with it, and that this cannot be undone.

    docs.attensira.com · retrieved

    “Permanently stops tracking a prompt and frees its slot. Its historical data goes with it and this cannot be undone — fetch it first if you want it.”

  2. Attensira's tool reference states that after a prompt is removed no new readings are collected, so any trend line for it ends on the day of removal.

    docs.attensira.com · retrieved

    “No new readings are collected for that prompt afterwards, so any trend line for it ends on the day you remove it.”

Next

The reference this is written from →Every endpoint →The same capability over MCP →