Resource model

The platform exposes a small set of resources. Understanding how they relate is enough to build almost any solution on top.

The resources

• Account — who owns things. Your integration authenticates as an account. An account can create subaccounts beneath it, so you can give each customer, team, or tenant its own isolated space and its own key.
• API key — how an account authenticates. A key belongs to exactly one account and only ever sees that account’s data.
• Tag — the digital identity bound to a physical item. Tags belong to an account. A tag is what gets scanned.
• Session — one verification flow against a tag. A session groups the scans that make up a single two-scan check.
• Verification — the verdict for a scan: pending, valid, or invalid. Verifications belong to a session.

How they relate

Account ──┬── owns ──▶ API key   (one account, many keys)
          └── owns ──▶ Tag       (one account, many tags)

Tag ──── has ──▶ Session ──── has ──▶ Verification
                 (one scan flow)      (the verdict)

• An account owns its tags and its API keys.
• A tag accumulates sessions — one per scan flow.
• A session holds the verifications produced as the flow resolves: a pending on the first scan, upgraded to valid or invalid on the second.

Subaccounts: multi-tenant by design

Accounts nest. The account that owns your API key is your master account; every account you create through the API becomes a subaccount of it, with a fresh key of its own.

This is the tenancy primitive. A solution typically provisions one subaccount per end customer, stores that subaccount’s key, and provisions that customer’s tags under it. Because a key only sees its own account’s tags, tenants are isolated from each other automatically — a scan validated with one subaccount’s key can only ever resolve a tag that subaccount owns.

Identifiers

Every resource has a prefixed, URL-safe id you’ll see throughout the API:

The prefix tells you the type at a glance; treat the whole string as an opaque identifier.