Expire a share

DELETE /v1/shares/{shortCode}

Requires the shares:write scope. Ends a share your account created, immediately, whatever its expired_at or remaining views said.

{shortCode} is the short_code from the create response, not a database id.

Request

curl -X DELETE https://api.credenshare.io/v1/shares/a1b2c3d4 \
  -H "Authorization: Bearer crs_sk_live_<keyId>.<authSecret>"

Success response

200 OK, with a body:

{
  "success": true,
  "message": "ok"
}

What "expire" means

The share is expired, not scrubbed from existence. The record moves into CredenShare's expired-share history so it still appears in your account's history and audit trail, and the link stops working from that moment.

The content is unreachable either way. It was only ever ciphertext here, and the key was only ever in the link.

There is no undo. A share cannot be un-expired, so recovering from a mistaken call means creating a new share — which means a new content key, a new short code and a new link.

Scope and ownership

You can expire shares belonging to your own account. A short code that is not on your account returns 404, exactly as it does on retrieve, so the endpoint cannot be used to learn whether a short code exists elsewhere.

The shares:write scope is required. It is the same scope as create, and scopes are matched exactly — a read-only key cannot expire anything.

Webhooks

A successful call emits the share.deleted event:

{
  "event": "share.deleted",
  "short_code": "a1b2c3d4"
}

Two details matter if you subscribe to it:

• The payload carries short_code and nothing else. No title, no timestamp in the body, no reason.
• The event is attributed to the share's owner, not to the caller. When a team key expires a share, the endpoints that receive the event are the owner's.

Errors

A repeated call on the same short code returns 404, because the first call already removed it from the active set. Treat 404 as an acceptable outcome when your goal is "make sure this share is gone".