# Get all lost cards

`GET /api/configuration/lost-cards`

- **Success:** `200 OK`
- **Products:** Operator (`FOH`)
- **Features:** Front of House Generic Access (`FOHGENERIC`)

HTML version: [Get all lost cards](https://support.gladstonesoftware.cloud/reference/configuration/get-all-lost-cards)

## 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](../../guides/authenticating-with-gladstone-apis.md).

## Sample request

```bash title="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](create-lost-card-record.md) 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

```json title="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. |