Compliance

Inscribe in a decision flow.

A Connection node calls Inscribe mid-decision with the credentials your own contract issued. Whatever comes back is data the rest of the flow can read, branch on, and keep in the decision's trace.

Category: Compliance
Type: Integration
Authentication: api_key
Test environment: Production host only

What a flow can call

5 operations, each one a step you can place on the canvas.

POST/api/v2/customers
Create a customer
Everything in Inscribe hangs off a customer, so this comes first — the documents and the fraud verdict attach to the id it returns.
GET/api/v2/customers/$data.inscribe_customer_id/documents/$data.inscribe_document_id
Get a document's fraud verdict
The call a decision actually branches on. trust_score runs 0 to 100 and risk_assessment.insights lists the individual fraud signals with a rationale — which is what an adverse action file needs, rather than the bare score.
GET/api/v2/customers/$data.inscribe_customer_id/documents
List a customer's documents
Every document on the customer with its state and scores.
GET/api/v2/customers/$data.inscribe_customer_id
Get a customer's risk assessment
The customer-level view: the risk assessment rolled up across every document, plus the canonical profile Inscribe derived from them.
GET/api/v2/customers
List customers
Customers on the account, newest first. Cheapest way to confirm a token works before wiring anything else.

Provider documentation: https://docs.inscribe.ai/reference/getting-started

Where it sits in the decision

A provider call is a node, not a side effect.

The call runs where the policy needs it — after the cheap checks that might make it unnecessary, before the rules that depend on it. Calls that do not depend on each other run together rather than in sequence.

Because it is part of the run, the response is part of the record. When someone asks why an applicant was declined months later, what Inscribe returned at the time is in the trace, not re-fetched from a service whose answer has since changed.