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
idrequired | The 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 successcurl -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
| Code | Cause |
|---|---|
204 | Deleted. No body |
401 | Token missing, malformed, or unknown |
404 | No such message, already expired, or outside your namespace |
429 | Too 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.