# Typed IDs

Thor resource IDs are opaque strings with a resource prefix.
Pass the complete returned value unchanged.
A prefix helps identify the kind of resource, but it is not an instruction to construct or rewrite the rest of the ID.

## Avoid common identity mistakes

| Operation | Use |
| --- | --- |
| Add a catalog item to a cart | Variant ID |
| Update or remove an existing cart line | Cart line-item ID |
| Create an order fulfillment line | Order line-item ID |
| Select a cart's price channel | Channel ID |
| Call a project endpoint | Project slug, not store ID |

Product variants commonly use `vid_`, channels use `ch_`, stores use `store_`, and products use `product_`.
These are recognition examples only.
Use real values from your project, not placeholders such as `vid_...` in an executed request.

## Persist relationships

Use IDs for durable API relationships.
Use names and slugs for presentation where appropriate, with a deliberate URL policy.
Keep external-system IDs in your integration mapping rather than replacing Thor IDs with them.
Treat each environment's mapping separately.

Do not decode the payload, infer creation time, change casing, or swap prefixes.
Keep IDs as strings in application state and storage.
A GraphQL `ID` argument can still require a particular resource type.

## Agent-friendly examples

Guides use placeholders such as `<variant-id>` and `<cart-id>` when values must come from an earlier step.
Replace them only after obtaining that resource from the correct project.
A placeholder is not a sample credential or a valid generated ID.

See [GraphQL basics](/concepts/graphql-basics) and [Connect to a project](/getting-started/connect).