# How it works

The moving parts, and when your solution and the platform talk to each other.


The platform has one job: it holds the identity of every tagged item and rules
on whether a scan is genuine. Everything a person sees stays yours. The page,
the app, the branding, the product data behind it: your solution owns all of
it, and calls the platform when it needs a verdict.

## The parts

[Image: Three rows, read top to bottom. In the real world a tagged item is tapped by a consumer phone. The tag URL opens your application, your application asks the TAGBASE platform to verify the scan, the platform looks the tag up in its database and reads its history, and the verdict travels back up through the platform to your application and on to the phone, where a green tick confirms the item is genuine.. See the web version of this page.]

- **Tagged item**: a physical thing carrying a dynamic NFC tag. Each tap emits
  fresh scan data, which is what makes a copied tag detectable.
- **Consumer phone**: any phone with NFC. A tap opens a URL, so the person has
  nothing to install.
- **Your solution**: your site, app, or backend. The URL on the tag points at
  your server, so the phone lands on your solution. It pulls the scan data out
  of the URL, asks the platform to rule on it, and decides what the person sees.
- **TAGBASE**: the API your solution builds against. It owns tags, teams, and
  the rules that turn scan data into a verdict.
- **Database**: where the platform keeps tags, sessions, and verifications. You
  reach it through the API, never directly.

The tag never talks to us. Every request the platform sees comes from your
solution, authenticated with your API key, which is why the person tapping
stays on your domain and inside your branding the whole way.

## When your solution calls the platform

Your solution starts nearly every exchange. The calls group into a few
moments, and they run on different clocks.

| Moment | What you call | How often |
|--------|---------------|-----------|
| Setting up a tenant | Create a [subteam](/docs/overview/resource-model) and its API key | Once per customer |
| Provisioning items | Create [tags](/docs/api/tags), one per item | Once per item, in batches |
| A scan | Submit the scan data, read the [verdict](/docs/api/verifications) | Every tap, on the hot path |
| Looking back | Read [sessions](/docs/api/sessions) and verifications | Whenever you like |

Only the scan sits between a person and their answer. Treat it as the one call
that has to be quick, and let the rest happen in the background.

## When the platform calls your solution

Some things happen to your tags without your solution asking. A tag gets
written to a chip on a production line, and days later that chip reaches a
shelf. Polling for that is wasteful, so the platform posts the news to a URL
you register. That is a [webhook](/docs/api/webhooks), and it is the one place
where the traffic runs the other way.

Every delivery is signed with a secret only you and the platform hold. Check
the signature on arrival and reject anything that fails, since an unsigned post
could have come from anyone.

## A scan, end to end

1. Somebody taps the item. The tag emits fresh scan data into a URL that points
   at your server.
2. The phone opens that URL. Your solution receives the tap and pulls the scan
   data out of it.
3. Your solution submits that data to the platform, together with the tag it
   belongs to.
4. The platform checks the data against what it holds for that tag and records
   the result in its database.
5. The platform answers with a verdict: `pending`, `valid`, or `invalid`.
6. Your solution shows the person the result.

The first tap on an item returns `pending` and asks for a second tap. A genuine
tag produces different data the second time, which resolves the check to
`valid`. A copy repeats itself and resolves to `invalid`. See
[verifications](/docs/api/verifications) for the full state machine.

## What stays yours

The platform stores no product catalogue and no customer accounts, and it has
no view on how a verdict should look on screen. It answers one question about
one tag; everything around that is yours to build.

## Where to go next

- [Resource model](/docs/overview/resource-model): how teams, tags, sessions,
  and verifications relate.
- [Your first verification](/docs/getting-started/your-first-verification): your first verification in three
  API calls.
- [Building a solution](/docs/guides/building-a-solution): the same flow as a
  working integration.
- [Best practices](/docs/guides/best-practices): private browsing, reloads,
  and the session the second tap must reuse.