Access log

GET /v1/shares/{shortCode}/access-log returns a share's access log, newest first: the same history the app shows under Access History. It needs the audit:read scope.

Who can read it

Only the share's creator, while the share is live and after it has ended (by date, views or deletion). A team key reads its holder's own shares, not another member's. Any other short code answers 404, so a key cannot learn whether a code exists.

The plan's access-log retention applies: entries older than that many days are not returned, whatever from says. retention_days and effective_from say which window was used.

Query parameters

Request

curl "https://api.credenshare.io/v1/shares/AbC123/access-log?limit=50" \
  -H "Authorization: Bearer crs_sk_live_<keyId>.<authSecret>"

Response

{
  "short_code": "AbC123",
  "entries": [
    {
      "accessed_at": "2026-10-25T18:00:00Z",
      "accessed_ip": "203.0.113.7",
      "platform": "macOS",
      "user_agent": "Mozilla/5.0 …",
      "failed_passcode": false,
      "signed_in": false
    }
  ],
  "next_cursor": "eyJ0Ijo…",
  "retention_days": 180,
  "effective_from": "2026-04-28T18:00:00Z",
  "effective_to": "2026-10-25T18:00:00Z"
}

• failed_passcode: the viewer entered a wrong passcode.
• signed_in: the viewer was signed in to CredenShare.
• user_agent is the raw header. Link previews and mail scanners identify themselves there, which is how the app and the CLI name them.

Pagination

Pass next_cursor as cursor to read further back. It is null on the last page. A page stays stable while new views arrive, because the cursor marks a position in the log rather than an offset.

ETags

Each response carries a weak ETag. Send it back as If-None-Match and an unchanged page answers 304 with no body, which makes polling for new views cheap.

Errors