Get all lost cards

GET /api/configuration/lost-cards

Success: 200 OK

Products: Operator (FOH)
Features: Front of House Generic Access (FOHGENERIC)

Overview

Lists every entry in the lost cards register: the cards members have reported lost, and when.

Despite sitting under configuration, this is not a small fixed lookup. It is an operational log that grows with the tenant: one entry per card reported lost, for every member, since the tenant was created. There is no filter parameter, no date range, no guaranteed order and no paging — you get the entire register on every call. On an established site that can be a very large response, and it contains member ids, so treat it as personal data rather than reference data: fetch it rarely, do not log it wholesale, and consider whether you need it at all rather than fetching a single card by its id.

Records are never expired or archived by the platform. A card reported lost years ago is still returned, and there is no status field distinguishing a resolved report from a live one — deletion is the only way an entry leaves the list.

When the register is empty you get 200 with an empty array []. A card reported lost moments ago may not appear straight away — do not use this endpoint as a real-time block list.

Endpoint

GET {base_url}/api/configuration/lost-cards

{base_url} is the environment URL issued to your integration. See Authenticating with Gladstone APIs.

Sample request

cURL

curl -X GET '{base_url}/api/configuration/lost-cards' \
  -H 'Authorization: Bearer {accessToken}' \
  -H 'X-Use-SSO: true'

Response fields

Field	Type	Description
`[].id`	string	The entry's identifier, unique within the register. Up to 255 characters. It takes one of two forms: for entries created through Create lost card record it is an upper-case GUID generated by Gladstone, and the entry records no card number; for other entries, such as those created automatically when a member's record is purged, it is the card number that was reported lost. Compare it as an opaque string: card numbers are issued by the operator's own hardware and encoding scheme, so there is no format to parse and no cross-tenant meaning.
`[].memberId`	integer (int32)	The member the card belonged to when it was reported lost. It normally resolves to a member — but watch for `-999`. When a member is purged for data protection, their lost card entries are rewritten to that sentinel rather than deleting them, so the card stays blocked while the person is anonymised. Treat `-999` as "member removed", not as a member id to look up. `null` is possible too, on entries recorded without a member.
`[].raisedDate`	string (date-time)	When the loss was reported, as a date and time. Nullable, and not defaulted — an entry created without one keeps `null`, so you cannot rely on this to order the register or to work out how old a report is. Note also that entries created during a member purge carry local site time rather than UTC, so do not assume a consistent time zone across entries; use it for display, not for arithmetic across records.

Sample response

200 OK

[
  {
    "id": "string",
    "memberId": 12345,
    "raisedDate": "2026-08-14T19:00:00Z"
  }
]

Errors

Status	Meaning	When
`500`	Internal server error	Any unexpected server-side failure while reading the lost card register. The response is a bare status code with no body, so there is no detail to branch on. On a large register a timeout is the likeliest cause, since the endpoint has no paging and always returns the whole register. Retry with backoff.

This page as markdown · All pages · llms.txt