List shares

GET /v1/shares

Requires the shares:read scope. Returns the shares your key created, newest first.

Query parameters

Both parameters are tolerant rather than strict. A value that is not a positive integer — ?limit=abc, ?page=0 — is treated as absent and the default applies. You will not get a 400 for a malformed pagination parameter, so check the pagination block in the response rather than assuming your input was honoured.

Ordering

The list is always ordered newest first, by creation time. There is no sort parameter, and the ordering is not caller-supplied — it is a fixed value, so there is no place for a caller to inject one.

Request

curl "https://api.credenshare.io/v1/shares?page=1&limit=25" \
  -H "Authorization: Bearer crs_sk_live_<keyId>.<authSecret>"

Success response

200 OK.

{
  "shares": [
    { "short_code": "a1b2c3d4", "expired_at": "2026-09-01T00:00:00Z" },
    { "short_code": "e5f6g7h8", "expired_at": null }
  ],
  "pagination": {
    "page": 1,
    "limit": 25,
    "total_pages": 3,
    "total": 61
  }
}

The pagination block is always present, so a client never has to guess whether more exists.

shares is an empty array — not null — when there is nothing to return.

What the list includes

The scope of the list is narrower than "everything on the account", in ways worth knowing before you build reconciliation on top of it:

• Only shares your key's user created. An organization-scoped key does not see teammates' shares.
• Only shares that are still usable. A share that has expired, run out of views, or run out of passcode attempts is not in the list. If a short code you created is missing, that is the likely reason.
• No secure-request submissions. Content submitted to you through a secure request is a separate thing and never appears here.
• Organization scoping is exclusive. A key that acts in a team sees only that team's shares. A key with no team sees only shares with no team. There is no combined view.

Errors