API Authentication | DigiBridge

Access map

Public, workspace and device access.

Public preview

Verifier API GET requests are unauthenticated and limited to approved public preview records.

Workspace session

Private application requests use your signed in account access token and current permissions for the requested workspace. Protected tool actions also require the current identity eligibility.

Paired device

Simulator routes use a one time pairing flow followed by a device bearer token. The server stores its hash and rechecks the account’s eligibility and authority.

Public surface

Do not send secrets to the Verifier API.

The public resolver is designed for published information. Adding an Authorization header does not unlock private records or additional trust fields.

GET/api/verifier/v1/resolve?code=<publicVerifyId_or_slug>

Public record resolver

Returns approved public preview context or a generic not found response.

Access: Public, no API key

public request

curl "https://digibridge-home-pages.vercel.app/api/verifier/v1/resolve?code=<publicVerifyId_or_slug>"

Application surface

Workspace routes use a signed in user token.

The web application sends the signed in account access token as a Bearer credential. This token is a Firebase ID token in the current interface. Access still depends on the workspace role and current identity eligibility for protected actions. This is the web application’s access model, not a separately licensed organisation API.

account request header

Authorization: Bearer <firebase_id_token>
Content-Type: application/json

Workspace boundary

Each protected request must carry a valid account token
Current identity eligibility is a separate Sumsub requirement for protected tools
Workspace access is checked server side on every protected route
Viewer roles cannot use write protected operations
Use the documented public API or agree a separate organisation interface

Device interface reference

Pair once, store the device token locally.

The simulator contract uses a short lived pairing code generated by an authenticated workspace. Registration returns the device token once. DigiBridge stores only its hash.

POST/api/daemon/devices/pair-code

Create a 10 minute pairing code

Requires current identity eligibility and workspace administration for this simulator interface.

Access: Signed in account access token

POST/api/daemon/devices/register

Register a simulator or development device

Consumes the workspace ID and pairing code, then returns a one time device token.

Access: Short lived pairing code

POST/api/daemon/proof-events/ingest

Submit a signed simulator event

Validates the paired device, canonical event hash, Ed25519 signature, replay state and previous event continuity.

Access: Device bearer token or X-DigiBridge-Device-Token

paired device headers

Authorization: Bearer <one_time_device_token>
# Or: X-DigiBridge-Device-Token: <one_time_device_token>

Recording and analysis

A sign in token is not permission to collect more data.

Device pairing, permission to record a chosen project and permission for AI analysis serve different purposes. The film verification workflow requires separate analysis permission. The public v1 API has no route for granting that permission or starting an analysis job.

Keep authority specific

An invitation grants only its stated workspace, project or asset scope
A public profile badge does not unlock recording or private records
A device token must not be reused as an organisation API key
Permission withdrawal and changed account access must be respected

Organisation integrations

Discuss service access before integration.

The public v1 contract covers record lookup. Organisation credentials, webhook behaviour, quotas and service expectations require a separate agreed integration contract.

Confirm these in your integration agreement

DigiBridge secret API keys
Published rate limit headers or quotas
Webhook signatures and retry contracts
Usage billing or enterprise SLAs

Connect with the right level of access.