> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kwugwo.africa/llms.txt
> Use this file to discover all available pages before exploring further.

# IDs & prefixes

> How Kwugwo IDs are structured.

Every resource exposed by the API has an ID with the shape:

```
<prefix>.<workspace>.<unique>
```

For example: `ugw.VCvr.7K2qPmRtV9xLnQ8sD1cYwHfE`.

* **`<prefix>`**: three letters identifying the resource type.
* **`<workspace>`**: a 4-character segment derived from the
  workspace (your nzube). It makes IDs easier to scan in logs, but
  it is **not unique on its own**; different workspaces *can*
  share the same 4-character segment, especially as the platform
  grows. Always use the full ID when looking a resource up; don't
  treat the workspace segment as an identifier.
* **`<unique>`**: a 24-character random identifier. This is what
  actually makes the ID unique across the entire platform. In the
  [sandbox environment](#sandbox-suffix), the last two characters
  are always `_t`.

## Prefix reference

The regexes below match **live** IDs. For **sandbox** IDs, replace
the trailing `[a-zA-Z0-9]{24}` with `[a-zA-Z0-9]{22}_t`; see [Sandbox
suffix](#sandbox-suffix) for the unified form.

| Prefix | Resource                                                                                | Format regex (live)                    |
| ------ | --------------------------------------------------------------------------------------- | -------------------------------------- |
| `ugw`  | Ugwo (payment request)                                                                  | `ugw\.[a-zA-Z0-9]{4}\.[a-zA-Z0-9]{24}` |
| `act`  | Activity (on an ugwo)                                                                   | `act\.[a-zA-Z0-9]{4}\.[a-zA-Z0-9]{24}` |
| `ony`  | Onye (customer)                                                                         | `ony\.[a-zA-Z0-9]{4}\.[a-zA-Z0-9]{24}` |
| `chk`  | Checkout                                                                                | `chk\.[a-zA-Z0-9]{4}\.[a-zA-Z0-9]{24}` |
| `psp`  | Nzube PSP configuration                                                                 | `psp\.[a-zA-Z0-9]{4}\.[a-zA-Z0-9]{24}` |
| `evt`  | Webhook event (the `uid` on the [delivery envelope](/webhook-deliveries#body-envelope)) | `evt\.[a-zA-Z0-9]{4}\.[a-zA-Z0-9]{24}` |

## Sandbox suffix

Kwugwo runs a separate [sandbox environment](/introduction#environments)
at `sandbox-api.kwugwo.africa`. Sandbox and live data are fully
isolated; a sandbox ID is never resolvable against the live API and
vice versa.

**Every sandbox ID ends in `_t`.** The last two characters of the
24-character unique segment are replaced with `_t`, leaving 22
random characters followed by the marker:

```
ugw.VCvr.7K2qPmRtV9xLnQ8sD1cYwH_t
                              ↑ sandbox marker
```

Live IDs keep all 24 characters random and never end in `_t`. This
makes it impossible to confuse a sandbox object for a live one at a
glance in a log line, an email, or a support ticket. The check is
also useful in code: a quick `id.endsWith('_t')` tells you whether
you're holding test data.

### Combined regex

If you need a single regex that accepts both environments, the unique
segment is `[a-zA-Z0-9]{22}(?:[a-zA-Z0-9]{2}|_t)`. For example, the
full pattern for an ugwo ID is:

```
ugw\.[a-zA-Z0-9]{4}\.[a-zA-Z0-9]{22}(?:[a-zA-Z0-9]{2}|_t)
```

The same shape applies to every other prefix in the table above.

## Why this format

* It's **grep-friendly** in logs.
* The prefix tells you what the ID is without consulting the
  database.
* The unique segment is long enough that you can safely log the full
  ID; it is not a secret.