Authorisation Terms
Authorisation terms define the legal text that users agree to when granting access to their data.System Terms vs Custom Terms
| Type | Description |
|---|---|
| System Terms | Default terms provided by Teal, available to all clients. Identified by is_system_term: true. |
| Custom Terms | Terms created by your organization for specific use cases. Identified by is_system_term: false. |
Categories
Each term belongs to a category that defines the type of authorisation:- one_time - Single authorisation for a specific action (e.g., one-time income verification)
- recurring - Ongoing authorisation for continuous data access (e.g., recurring payroll checks)
Retrieving Available Terms
Creating Custom Terms
If system terms don’t meet your requirements, create custom terms:authorisation_version is automatically assigned and incremented for each new term you create.
Managing Active Terms
By default, creating a new term keeps any existing active terms in the same category active. Use the optionaldeactivate_previous flag to control this behavior:
deactivate_previous | Behavior |
|---|---|
false (default) | New term is created. Existing active terms remain active. |
true | New term is created. Any existing active term for the same category is set to is_active: false. |
Getting the Latest Term for a User
To get the appropriate authorisation term for a user based on their recurring check configuration:one_time or recurring category based on the user’s configuration.
Recording Authorisation
When a user accepts authorisation terms, record their acceptance:term_id is optional. If it is absent in the request, then the latest active term is searched against the user’s current setting. For example, if
they have reucrring checks enabled then it will resolve to the latest active term matching this category. If the term_id is
supplied you can choose which term the user is accepting, provided it is active. No category matching is done currently for an
explcitly provided term.
Optional Fields
| Field | Behavior |
|---|---|
term_id | Optional. If not provided, auto-resolves to the latest active term based on user’s recurring check configuration. |
ip_address | Optional. If not provided, captured from request headers. Use when recording authorisation via server-to-server calls. |
Authorisation Record
Each acceptance creates an immutable record containing:- id - Unique authorisation record identifier
- user_id - The user who gave authorisation
- term_id - The specific term version accepted
- ip_address - Captured from request headers or provided in request
- user_agent - Browser or application identifier
- accepted_at - Server timestamp of acceptance
- status -
activeorrevoked
Validating Authorisation
Before performing actions that require authorisation, verify the user has accepted the current active terms.Check User’s Authorisation Status
Validation Logic
Each authorisation record includes anis_valid field that indicates whether the authorisation is currently valid:
is_valid: true- Authorisation status isactiveAND the associated term is activeis_valid: false- Either authorisation is revoked OR the term has been deactivated
is_valid is false because the term was deactivated, the user needs to re-authorise to the new term.
Re-authorisation Flow
When you update your terms, you can deactivate the old term usingdeactivate_previous: true (see Managing Active Terms). Users who accepted the deactivated term will need to re-authorise.
Flow
Example: Detecting Outdated Authorisation
Revoking Authorisation
Users can revoke their authorisation at any time. Revocation preserves the record for audit purposes.- The authorisation record’s
statuschanges torevoked - The
revoked_attimestamp is set - The record is preserved for compliance and audit purposes