ravenhook

Delete a message

DELETE/messages/{id}Bearer token required

Removes a message immediately rather than waiting for it to expire. Returns 204 with no body.

Path parameter

idrequiredThe message id we assigned

Example

import os, requests

reply = requests.delete(
    f"https://api.ravenhook.dev/messages/{message_id}",
    headers={"Authorization": f"Bearer {os.environ['RAVENHOOK_TOKEN']}"},
)

assert reply.status_code in (204, 404)
const res = await fetch(`https://api.ravenhook.dev/messages/${id}`, {
  method: "DELETE",
  headers: { Authorization: `Bearer ${process.env.RAVENHOOK_TOKEN}` },
});

// 204 deleted, 404 already gone - both fine to treat as success
curl -s -X DELETE "https://api.ravenhook.dev/messages/ed32433d12e145b19ee0117418d688b6" \
  -H "Authorization: Bearer $RAVENHOOK_TOKEN" \
  -o /dev/null -w "%{http_code}\n"

You usually do not need this

Messages are deleted automatically 24 hours after they arrive, and each run using its own address means nothing from a previous run can be mistaken for this one's. There is no cleanup step to write.

Deleting explicitly is worth it in two cases:

  • A test received something genuinely sensitive and you would rather it were gone in seconds than in a day.
  • You are reusing one address across sequential tests and want a known-empty starting state.

For the second, a fresh address per run is the better fix — it costs nothing and removes the ordering assumption entirely.

Errors

CodeCause
204Deleted. No body
401Token missing, malformed, or unknown
404No such message, already expired, or outside your namespace
429Too many requests

Deleting something that is already gone returns 404 rather than succeeding quietly. If your cleanup runs after retention has already removed the message, treat 404 as success — the desired state is the same either way.