Credits Domain

Overview#

An agency operates on a fixed budget for platform AI processing. As investigations become more complex and AI usage grows, the administrator needs to understand how credits are being consumed across teams and ensure that high-priority investigations have the processing capacity they need. The Credits domain provides that visibility and control: per-organisation credit balances, usage tracking, and low-balance alerts that surface before capacity runs out rather than after.

Key Features#

Credit balance tracking per organisation.
Usage-based credit deduction for platform operations.
Credit allocation and top-up management.
Transaction history with detailed audit trail.
Credit consumption analytics and reporting.
Organisation-scoped credit management.
Integration with subscription plans for credit allocation.
Low-balance alerting and notification.

Use Cases#

Government agencies managing fixed annual budgets for platform AI processing track credit consumption across investigation teams, ensuring that high-priority operations retain sufficient capacity throughout the financial year.

Platform administrators monitor credit balances and usage patterns per organisation, identifying units consuming credits at an unusual rate and investigating whether the usage reflects genuine operational need or misconfigured workflows.

Finance and operations teams generate credit usage reports for billing reconciliation and cost analysis, attributing platform costs accurately to the investigations and teams that consumed them.

Subscription plan managers allocate credits based on tier entitlements and operational needs, providing top-ups for organisations running complex multi-phase investigations that exceed standard tier allocations.

Integration#

Integrates with organisation settings, analytics, and subscription plan management for credit lifecycle tracking.

Open Standards#

GraphQL (June 2018 specification): All credit balance queries, transaction history, package listings, and purchase mutations are exposed through a typed GraphQL schema, allowing clients to request exactly the fields they need.
HMAC-SHA256 (RFC 2104 / FIPS 180-4): Incoming payment webhooks from Revolut are authenticated by computing an HMAC-SHA256 digest over a signed payload string and comparing it in constant time to the signature supplied in the request header, with a ±5-minute timestamp replay window enforced.
OAuth 2.0 Bearer Token (RFC 6750): Outbound calls to the Revolut Merchant API carry the platform's secret key as a Bearer token in the Authorization header, following the HTTP authentication scheme defined by RFC 6750.
ISO 4217 Currency Codes: All monetary amounts, balances, package prices, and transaction records, are stored alongside a three-letter ISO 4217 currency code (USD, EUR, GBP), with per-tenant currency resolved from stored locale preferences.
HTTP Semantics, 402 Payment Required (RFC 9110): The credit-gate middleware returns HTTP 402 when an authenticated organisation has a zero credit balance, communicating payment requirements to API consumers in the manner defined by RFC 9110.
JSON (RFC 8259): Webhook event payloads, GraphQL request and response bodies, and internal cost-event records are all serialised as JSON, the interchange format defined by RFC 8259.
ISO 8601 Date and Time: Transaction timestamps, usage-event dates, invoice issue and due dates, and order filtering parameters are represented as ISO 8601 date-time strings throughout the service layer.

Last Reviewed: 2026-02-05 Last Updated: 2026-04-14