# Get lost card by ID

`GET /api/configuration/lost-cards/{all}`

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

HTML version: [Get lost card by ID](https://support.gladstonesoftware.cloud/reference/configuration/get-lost-card-by-id)

## Overview

A lost card record marks one physical member identifier — an access card, keyfob or smartband — as reported lost or stolen. This endpoint reads a single such record back by the identifier value itself.

When no entry has that identifier, this endpoint returns **`404 Not Found`** with the plain-text body `GetLostCard could not find the id {lostCardId}`.

The `{all}` placeholder shown in the endpoint line below is not a literal path segment. The real route segment is the lost card id, as described under **Path parameters**. Requesting the collection path with nothing after the trailing slash does not fail — it matches the list operation and returns every lost card record instead of one, which is easy to do by accident when your id variable is empty.

`lostCardId` takes one of two forms. Entries created through [Create lost card record](create-lost-card-record.md) have an identifier generated by Gladstone, an upper-case GUID, and record no card number. Other entries, such as those created automatically when a member's record is purged, use the card number itself as the identifier. Either way it is unique within your tenant, so this lookup can only ever match one entry, and it is meaningful only inside one operator's system. Get valid values from [Get all lost cards](get-all-lost-cards.md).

Match the casing of the id exactly as the list endpoint returned it. Sometimes the id must match character for character, and sometimes a differently-cased id matches; the result is not consistent, so do not rely on either behaviour.

There is no active, resolved or archived flag on a lost card record, so a record stays retrievable until someone deletes it. Nothing in the response tells you whether the card was subsequently found or replaced.

## Endpoint

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

`{base_url}` is the environment URL issued to your integration. See [Authenticating with Gladstone APIs](../../guides/authenticating-with-gladstone-apis.md).

## Path parameters

| Name | Type | Required | Description |
|------|------|----------|-------------|
| `lostCardId` | string | Yes | The entry's identifier: either a card number or, for entries created through the API, a generated upper-case GUID. Maximum 255 characters, and unique within your tenant, so it identifies at most one entry on its own and you never need to supply a member id alongside it. Take it from [Get all lost cards](get-all-lost-cards.md) and preserve its casing. An identifier with no matching entry returns `404`. Leaving the segment empty routes the request to the list operation instead of failing. |

## Sample request

```bash title="cURL"
curl -X GET '{base_url}/api/configuration/lost-cards/{all}' \
  -H 'Authorization: Bearer {accessToken}' \
  -H 'X-Use-SSO: true'
```

## Response fields

| Field | Type | Description |
|-------|------|-------------|
| `id` | string | The entry's identifier, echoing the value you requested: a card number, or a generated upper-case GUID for entries created through the API. Maximum 255 characters. It is always populated and never repeats within a tenant. |
| `memberId` | integer (int32) | The member the identifier was issued to. **Nullable** — `null` means the record has no member attached, so do not assume you can always trace a lost card back to a person. When populated it is a tenant-scoped member id, not a value that travels between operators. |
| `raisedDate` | string (date-time) | When the loss was reported, as an ISO-8601 timestamp. This value is supplied by whoever created or updated the record rather than stamped by the server, and there is no default, so it is `null` on any record where the reporter did not set it — treat a missing date as "unknown", not as "reported now". Because it is caller-supplied, its accuracy and offset are only as reliable as the system that wrote it. |

## Sample response

```json title="200 OK"
{
  "id": "string",
  "memberId": 12345,
  "raisedDate": "2026-08-14T19:00:00Z"
}
```

## Errors

| Status | Meaning | When |
|--------|---------|------|
| `400` | Bad request | The request could not be read. The body is a validation error object keyed by field name. |
| `404` | Not found | No entry exists with that identifier. The body is the plain string `GetLostCard could not find the id {lostCardId}`. Do not retry the same identifier expecting a different outcome. |
| `500` | Internal server error | An unexpected server-side failure while reading the record. The response has **no body**, so there is nothing to parse. Retry once, then raise a support ticket quoting the id and the time of the call. |
