A session represents a single two-scan flow against one tag. It’s the thread that connects a first scan to its second so the platform can resolve them into one verdict.
Fields
| Field | Type | Notes |
|---|---|---|
id |
string | ses_-prefixed, assigned by the platform. |
A session belongs to a tag and groups the
verifications produced as the flow resolves — a
pending on the first scan, then its valid / invalid resolution on the
second.
Where sessions come from
You don’t create a session directly. The platform opens one for you on a first
scan and returns its id in the verification response, under
data.relationships.session:
"relationships": {
"session": { "data": { "type": "sessions", "id": "ses_abcdef0123456789" } }
}
Using a session
Carry that session id back as tagbase_session_id on the second scan so the
platform resolves the two scans together rather than starting a new flow. See
Verifications → The two-scan flow for the full
sequence.
A session is live for 10 minutes after its first scan. A second scan after that window opens a fresh session instead of resolving the old one.
Notes
- Sessions are not independently addressable — there is no endpoint to fetch a session by id. They appear only as a relationship on a verification. Hold the id on your side between the two scans of a flow.