Skip to content
CredenShare
Secure requests

Expire or delete a request

DELETE /v1/requests/{shortCode} — close a collect link, and on a second call remove it for good.
DELETE /v1/requests/{shortCode}

Requires the requests:write scope.

One method, two outcomes

This endpoint does something the share equivalent does not: what it does depends on the request's current state.

Request state when you callWhat happensoutcome
ActiveSoft-expired. The collect link stops working; submissions and their audit trail are kept."expired"
Already expiredPermanently removed."deleted"

The first call closes the link without destroying the record of what came through it. The second call, on a request that is already expired, is what actually removes it.

The response says which happened rather than leaving you to infer it:

{
  "short_code": "a1b2c3d4",
  "outcome": "expired"
}
A retry is not idempotent here. Calling this twice on an active request expires it, then permanently deletes it — including its submissions. A naive "delete until it stops erroring" retry loop will destroy the audit trail it was trying to leave alone. Branch on outcome, and stop after "expired" unless removal is what you actually want.

Request

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

{shortCode} is the short_code from the create response, not a database id, and not a submission's short code.

What expiry means for submissions already received

Expiring a request closes the collect link. Submissions already made are still there, and still readable through the submissions endpoint — an expired request is not the same as a deleted one.

Permanent deletion, on the second call, takes the submissions with it. There is no undo, and no recovery: the ciphertext was only ever openable with a key we never held, so there is nothing on our side to restore it from even in principle.

Ownership

Ownership is enforced in the handler, not in the service layer. The service permits a link-holder to delete in some configurations, which is correct for the recipient path in the app and wrong for a key acting on an account.

A short code on another account returns 404, indistinguishable from one that does not exist.

Errors

Statuserror_codeWhen
40044No short code in the path. DELETE /v1/requests is not a bulk delete.
40378The key lacks requests:write.
40470No such request on this account, or it has already been permanently deleted.
429107Rate limit exceeded. Retry-After gives the seconds to wait.
50011The request was found but could not be expired or deleted.

Once a request has been permanently deleted, further calls return 404. If your goal is "make sure this collect link is closed", treat both 200 and 404 as success — but see the warning above before retrying blindly.