Skip to content
CredenShare
Shares

Retrieve a share

GET /v1/shares/{shortCode} — one share's metadata, without touching the 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"
}
FieldTypeNotes
short_codestringThe short code you asked for.
expired_atstring or nullRFC 3339, or null when the share was created with no expiry.

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

This is not the recipient read path. It is an owner's metadata read, and it is deliberately built on a different code path so that polling your own share cannot damage it.
  • 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 exhausted by its view limit or its passcode attempts still reports whatever expired_at it was created with, including null.

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

Statuserror_codeWhen
40378The key lacks the shares:read scope.
4041No such share on this account.
429107Rate limit exceeded. Retry-After gives the seconds to wait.

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.