Invoice request
Proposed Trusted Billing submission; confirm schemas/provider mapping.
Request schema from OpenAPI
| Field | Type | Required | Constraints | Technical definition |
|---|---|---|---|---|
paymentRequestId | string | Yes | {"minLength": 1, "maxLength": 128} | Proposed paymentRequestId field. Synthetic identifiers must not contain personal data. |
acceptanceRef | string | Yes | {"minLength": 1, "maxLength": 128} | Proposed acceptanceRef field. Synthetic identifiers must not contain personal data. |
recipientRef | string | Yes | {"minLength": 1, "maxLength": 128} | Proposed recipientRef field. Synthetic identifiers must not contain personal data. |
Read the operation and next actions
Errors and next actions
A consistent error envelope guides recovery without disclosing sensitive data.
Read detailsReliability, concurrency and recovery
Retry design follows the side effect rather than repeating every request blindly.
Read detailsAPI Explorer — local simulator
Explore requests/responses and failure scenarios using synthetic data; no backend connection.
Read detailsContract boundary
Proposed Trusted Billing submission; confirm schemas/provider mapping.
Exceptions and reconciliation
After timeout, query state rather than create another transaction/command with an unknown prior outcome. Retain correlation/version/evidence without records or credentials in logs.
HTTP example — proposed contract
Request
POST https://records.example.invalid/v1/invoice-requests HTTP/1.1
Authorization: Bearer <example-token>
X-Tenant-Id: synthetic-tenant-001
X-Project-Id: synthetic-project-001
X-Correlation-Id: synthetic-correlation-001
Idempotency-Key: synthetic-key-001
Content-Type: application/json
{
"paymentRequestId": "synthetic-payment-001",
"acceptanceRef": "synthetic-acceptance-001",
"recipientRef": "synthetic-recipient-001"
}Response · 202
{
"invoiceRequestId": "synthetic-invoice-001",
"state": "REQUESTED"
}Required fields and shared controls
| Item | Proposed rule |
|---|---|
| scope | billing:write |
| required | paymentRequestId, acceptanceRef, recipientRef |
| tenant / project | Token and context must match; headers alone are insufficient. |
| idempotency | POST/PATCH: same key/body returns original result; changed body returns 409; confirm retention window. |
| error | code, message, requestId, correlationId, retryable, details; no sensitive data. |
Continue the workflow
Two journeys, one records lifecycle
Connect paper and born-digital records through persistent identifiers, policies and evidence.
Read detailsIntegration quickstart
Exercise ingest → job tracking → registration → verification with synthetic data.
Read detailsIntegrity, provenance and evidence
Each evidence type answers a different question; hashes, timestamps and approvals are not interchangeable.
Read detailsStart with a verifiable scope.
Agree record classes, quality criteria, permissions and evidence before scaling.
Plan assessment