Retrieve a share

GET /v1/shares/{shortCode}

Requires the shares:read scope.

The path parameter is a short code

{shortCode} is the short_code value the create response gave you, and the same value that appears in the recipient link. It is not a database id, and there is no other identifier for a share anywhere in this API.

This endpoint takes no query parameters.

Request

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

Success response

200 OK, with exactly two keys:

{
  "short_code": "a1b2c3d4",
  "expired_at": "2026-09-01T00:00:00Z"
}

That is the whole body. There is no title, no status, no view counter, no has_passcode, no created_at and no url.

What this endpoint does not do

• It does not return content. No endpoint on this API does. The content is ciphertext CredenShare cannot read, and the key that opens it lives in the link fragment.
• It does not consume a view. A share with access_counts_left: 1 still has one view left after you call this, however many times you call it.
• It does not evaluate a passcode, and it does not require one. There is nowhere to send a passcode_verifier here.
• It cannot expire the share. Expiry is reported, never acted on. Use DELETE when you actually want the share gone.

The reason it is a separate path at all is the encryption model: every read by short code on the recipient side requires the access token derived from the link fragment, and the server never holds that token. Routing an owner's metadata read through the recipient path answers "not found" for shares the caller demonstrably owns.

Knowing whether a share is still usable

The response does not tell you whether a share has been used up. A share whose last view has been used still returns its expired_at, as though it were still usable, until another attempt to open it or the hourly sweep removes it. From then on this endpoint answers 404. A share that runs out of passcode attempts is removed by the failed attempt that used the last one, so it answers 404 straight away.

Use GET /v1/shares for that question instead: the list excludes any share that is no longer usable, so a short code that is absent from the list is a short code nobody can open any more.

Errors

A short code that belongs to a different account returns 404, not 403, and so does one that never existed. The two are indistinguishable on purpose: a key must not be usable to discover which short codes exist elsewhere.