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

# Core concepts

> The building blocks of the Endstate API: collections, units, chips, verification, session tokens, tap redirects, and claims.

Every physical product you manage through Endstate has a digital record — a unit. When a user taps the NFC chip on that product, the API verifies the tap and returns proof of authenticity. Everything else in the API supports that moment.

## Concepts

<CardGroup cols={2}>
  <Card title="Collections" icon="layers" href="/concepts/collections">
    A group of related units — a product line, drop, or release. Create a
    collection first; it defines the namespace your units share.
  </Card>

  <Card title="Units" icon="box" href="/concepts/units">
    The unique digital record for a single physical item. Each unit belongs to
    exactly one collection and maps one-to-one with a physical product.
  </Card>

  <Card title="Chips & verification" icon="scan-line" href="/concepts/chips">
    A real, physical NFC chip (NTAG 424 DNA) on the item. Pairing a chip to a
    unit links hardware to its digital record. Each tap produces a one-time
    credential used to verify authenticity.
  </Card>

  <Card title="Session tokens" icon="key" href="/concepts/session-tokens">
    Short-lived proof that a specific chip was just tapped. Scoped to one chip,
    unit, and organization — safe to use from a client without exposing your API
    key.
  </Card>

  <Card title="Tap redirects" icon="corner-up-right" href="/concepts/tap-redirects">
    Control where a user lands after a tap — set a destination per unit, per
    collection, or org-wide. The most specific redirect wins.
  </Card>

  <Card title="Claims" icon="arrow-right-left" href="/concepts/claims">
    Hand a verified unit to its first owner, authorized by the session token
    from a recent tap of that unit's chip. Endstate can submit it for you.
  </Card>

  <Card title="Transfers" icon="repeat" href="/concepts/transfers">
    Move a unit between owners — tap-authorized like a claim, but the current
    owner submits the transfer from their own wallet.
  </Card>
</CardGroup>

## How they fit together

The concepts follow a single chain from setup to verification at the point of tap.

**1. Create a collection**

A collection groups related physical items under one namespace. You create it first (`POST /v1/collections`) and poll until it is ready before adding units to it. The collection defines the serial-number space that all of its units will share.

**2. Create a unit**

For each physical item, you create a unit inside the collection (`POST /v1/units`). The unit is the item's digital record — you can attach a name, an external ID that maps to your own systems, and free-form attributes. At this point the unit exists but has no serial number yet; that comes when a chip is paired.

**3. Pair a chip**

You pair an NFC chip to the unit (`POST /v1/chips`) to link the physical tag on the product to its digital record. Pairing triggers issuance: the unit receives a serial number within its collection and its issuance status moves from `pending` to `active`. A chip is permanently bound to one unit and cannot be re-paired.

**4. User taps**

When a user taps the product, the NFC chip delivers a `chip_id` and a one-time credential (an `e` value) — either via a tap URL in your application or through a redirect. The `e` value is single-use and is never logged. You can control where a tap lands — your own page or Endstate's hosted flow — with [tap redirects](/concepts/tap-redirects).

**5. Verify**

Your server sends the `chip_id` and `e` value to `POST /v1/chips/{chip_id}`. The API validates the credential, records the tap against the chip's scan count, and returns the unit's full metadata plus a session token. A successful response is confirmation the product is authentic.

**6. Use the session token**

The session token is short-lived proof that the tap just happened. You can pass it to `GET /v1/session-tokens/current` from a client to confirm its scope — which chip, which unit, and which organization it is bound to — without exposing your API key. A session token also authorizes the unit's ownership actions: **claiming** it via the [Claims API](/concepts/claims) and **transferring** it between owners via the [Transfers API](/concepts/transfers).

The complete flow in one line:

```
collection → unit → chip (paired) → tap → verify → session token → claim (optional)
```

## Next steps

* Follow the [Quickstart](/quickstart) to run a complete verification flow end to end.
* Read [Collections](/concepts/collections) for a detailed look at creating and provisioning a collection.