Typed IDs
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 and Connect to a project.