terms

accept

POST

/api/v2/terms/accept

Record acceptance of the terms version the caller was shown.

Code
Request body: {"key": "sql_editor", "version": "<content hash>"}

``version`` is required and must match the currently registered version. If
the notice changed after the page loaded, the request is rejected with a
``version`` field error so the client can reload and show the current text
rather than filing an acceptance for text the user never read.

Acceptance is blocked while impersonating: a legal acknowledgment must be
made by the user directly, not on their behalf.

With ``reports.enable-sql-editor-terms`` off, the call succeeds without
recording an acceptance.

Request and response schemas are located at
'lib/api/api_specs/request-terms_accept.json' and
'lib/api/api_specs/response-terms_accept.json', respectively.

accept › Request Body

Request payload for /api/v2/terms/accept - record that the current user accepted a specific version of a terms document. Appends an acceptance row and an audit note atomically. Refused while impersonating, and refused for users who cannot use the feature the terms cover (BriteCore staff, isGod, are exempt from that check).

request-terms_accept

key

string · enum · required

Identifier of the terms document, validated against the in-repo registry (core.terms_of_service). An unknown value is rejected.

Enum values:

sql_editor

version

string · required

The version the caller actually displayed, as returned by /api/v2/terms/status. Always required. While the site shows the notice it must equal the currently registered version: sending the key alone would let a notice edit between page render and submit produce an audit row claiming the user accepted text they never saw, and a mismatch is rejected with a version field error so the client can reload and show the current notice. On a site where reports.enable-sql-editor-terms is off the notice is not in force, so nothing is recorded and a stale value is tolerated rather than rejected.

api_key

string

API key for authentication

accept › Responses

200

Response payload for /api/v2/terms/accept - confirmation of the recorded acceptance. Idempotent per (contact, document, version): a retried acceptance returns the row already on file rather than failing, and writes no second audit note. Validation failures are returned in this same envelope with success:false at HTTP 200, not as a non-2xx status.

response-terms_accept

success

boolean · required

object

The recorded acceptance. On a site where reports.enable-sql-editor-terms is off the notice is not in force: no acceptance row and no audit note are written, and this reports the registered version rather than the submitted one, so an already-open dialog can close instead of erroring.

status

POST

/api/v2/terms/status

Return the ToS acceptance status for the current user.

Code
Request body: {"key": "sql_editor"}
Returns: {accepted, current_version, text, effective_date,
          previously_accepted_older_version}

Request and response schemas are located at
'lib/api/api_specs/request-terms_status.json' and
'lib/api/api_specs/response-terms_status.json', respectively.

status › Request Body

Request payload for /api/v2/terms/status - read whether the current user has accepted the current version of a terms document. Read-only. Callers who cannot use the feature the terms cover are refused, matching the page gate, so that acceptance state is never surfaced or recorded for users without access (BriteCore staff, isGod, are exempt from that check).

request-terms_status