---
title: "Delete a notification"
method: DELETE
path: "/v1/{account_id}/notifications/{card_urn}"
tags: ["Notifications"]
---

# Delete a notification

`DELETE /v1/{account_id}/notifications/{card_urn}`

## Request

- Base URL: `https://api.curviate.com`
- URL: `https://api.curviate.com/v1/{account_id}/notifications/{card_urn}`
- Auth: HTTP bearer

Deletes one of the connected account's own notification cards by its card urn. This is a self-action, no third party is notified. It cannot be undone. Pass the `card_urn` of a notifications list item (not object_urn).

## Path parameters

- `account_id` string, required
- `card_urn` string, required

## Response `200`

The notification card was deleted. This cannot be undone.

**Safe to retry.** Deleting a card you already deleted succeeds with 200 again, it is not an error, and it does not delete anything else. A client that retries after a network timeout is never punished for it. (A `card_urn` that never existed on this account is a 404; that distinguishes a wrong handle from a repeat.)

**Timing.** The removal takes effect within a few seconds; a notifications list read immediately after this call may still include the card for a moment. If you need to confirm removal, re-read after a short delay rather than instantly; but the 200 is already your confirmation that the card was resolved and the removal accepted.

- object
  - `object` 'notification_deleted', required: Response type discriminator.
  - `card_urn` string, required: The card urn that was deleted.
  - `safety_warning` SafetyWarning: Present on a successful response when this account crossed an account-safety ceiling while the affected budget row is on the default warn posture. The action still happened. Field-identical to the BUDGET_EXHAUSTED error body except that blocked is false and hint.message describes the outcome, so one branch handles both postures and switching the account to enforce is a configuration change rather than a client rewrite.
    - `row` string, nullable, required: The budget row that breached, for example profile_views or pending_invites. Null when the breach is not about a row: an activity_window warning on an action that spends no budget of its own (editing a message, dismissing a notification, a Recruiter or Sales Navigator admin action) is still governed by the hours the account works in. Read hint.parameter for what to change; whenever this is null it names posture, because the activity window edges are set per action type and this action has none, so the levers that reach it are the account timezone and posture.
    - `reset_at` string, nullable, required: The instant the refusal lifts: the window roll on a ceiling refusal, the next window open on an activity-window one. Null in the two cases no clock frees, the pending_invites gauge and InMail credits (row inmail).
    - `hint` object, required
      - `parameter` string, required: The settable parameter on PATCH /v1/{account_id}/safety-policy.
      - `message` string, required: What the condition is and what changing that parameter would do. This is the one field whose text differs from the BUDGET_EXHAUSTED refusal: here it says the action went through, and on a ceiling breach how far past the ceiling this row now stands, rather than telling you to set posture to warn when it already is. Branch on parameter, reason and blocked, never on this text.
    - `reason` 'ceiling' | 'activity_window', required: Which rule was crossed. ceiling means the row's configured limit is spent; activity_window means the account is outside the hours it works in, which is a different fact with a different remedy. hint.parameter names the right setting for each.
    - `blocked` boolean, required: Always false here. True on the BUDGET_EXHAUSTED refusal carrying the same payload.

## Other responses

- `400`: Invalid request, `card_urn` is not a notification card urn (pass the item's `card_urn`, not `object_urn`).
- `401`: The connected LinkedIn account's session is disconnected, reconnect the account.
- `404`: The account_id does not belong to this tenant or is unknown, or the `card_urn` does not exist on this account (it belongs to another account, or never existed). Deleting a card that you already deleted is NOT a 404; it succeeds with 200; see the 200 description. An id whose connection was replaced or removed also stops resolving here, and it is already absent from the list, so re-read `GET /v1/accounts` for the current id.
- `413`: Payload too large, the request body exceeds the size limit.
- `429`: Rate limited, retry after the hinted delay.
- `500`: Internal error.
- `502`: A temporary upstream error occurred, or the upstream response could not be interpreted. Check `retry_likely_to_succeed`: a temporary error is worth retrying, a response that could not be interpreted is not, and carries `retry_hint: {"kind": "never"}`.
- `503`: Service unavailable.
- `504`: Gateway timeout.

---

[API](https://skmtc.dev/curviate/apis/curviate-api.md) · [All operations](https://skmtc.dev/curviate/apis/curviate-api/llms.txt) · [OpenAPI document](https://skmtc.dev/curviate/apis/curviate-api/revisions/eab848801d95?raw)