Glossary

One definition per term, each linking to the page that covers it in depth. The reference pages, the code samples and the MCP tool manifest all use these words with exactly these meanings.

Cascades and runs

Cascade (API resource: workflow) — a decision workflow: which reports to pull, in what order, which rules to evaluate, and what happens on each outcome. The visual builder and the API expose the same object; over the API it is named workflow and its node graph lives in definition. See Cascades and the Workflow schema.

Workflow — the API name for a cascade. GET /workflows lists them; active: false marks a draft that can run once in test mode but not live. See Cascades.

Node — one step in a cascade's definition: an ApplicantSource entry point, a BillingProduct that pulls one report, an IfElse that branches, a Wait, a GoTo, an Action (approve, email, adverse action, notification) or a terminal ShowResults. Nodes are wired by edge keys such as next_step, pass_steps, human_review_steps and fail_steps. See What is in the definition? and the CascadeNode schema.

Execution — one run of a cascade for one applicant. POST /workflows/{id}/trigger creates it and answers 202 Accepted; the work happens in the background and everything about it hangs off GET /executions/{id}. See Executions and the Execution schema.

Step outputs (step_outputs) — a map of node id to that node's output on an execution: the report fields a product node returned, which branch an IfElse took and why, what an action did. Returned only to keys with the executions:read:full scope because it routinely contains per-step PII. See How do I read the decision?.

Batch — one cascade run against many applicants in a single request. Cascades pre-creates a child execution per row and works through them in the background; the batch tracks progress and exports the results. See Batches and the Batch schema.

Decision — the outcome an IfElse node reaches for an applicant: pass, fail or send to human review, each resuming its own branch of nodes. The execution's final status, step_outputs and any adverse-action notice are the API view of that decision; the operator app and the tenant-screening ScoreCard present the same run as a summary page. See Executions and Human review.

Modes and access

Sandbox vs live — the two hosts and the two ways a run can execute. Every run carries an execution_mode of test (synthetic mock data, nothing billed) or live (real consumer reports, billable, requires an approved account and an active cascade). See Sandbox vs live.

execution_mode — the per-request field that selects test or live. It is chosen per trigger, not per key, so the same integration moves to production by changing one value; keys minted from these docs are pinned to test. See Sandbox vs live and the TriggerRequest schema.

API key — the bearer token sent as Authorization: Bearer <key> on every request. Keys are minted at /api-keys, carry a set of scopes, and see only the workflows, executions and subscriptions of the account that issued them. See Keys, scopes and rate limits.

Scope — a permission attached to an API key, such as workflows:read, executions:write or executions:read:full. A request that needs a scope the key lacks returns 403 insufficient_scope; each operation's reference page lists the scopes it requires. See Which scopes exist?.

Idempotency key — the Idempotency-Key header required by every endpoint that creates a run (trigger, batches, re_evaluations). A retry with the same key and body returns the original result instead of starting a second run; the same key with a different body is 409 idempotency_conflict. See Idempotency.

Test identity (registered test subject) — a synthetic applicant authored in the CRS sandbox test-case registry with a specific history. GET /workflows/{id}/test_cases returns the subjects that match a cascade's products with ready-to-send payloads; a test-mode trigger for a subject registered for every product node in the cascade replays its authored reports, and other test runs return schema mocks. See Test identities.

Registry — the CRS sandbox test-case registry that holds the test identities and the bureau responses replayed for them. See Test identities.

Events and notices

Webhook event — a named change Cascades delivers to your endpoint as an HTTPS POST with a JSON envelope { id, event, created_at, data }, for example execution.completed or adverse_action.sent. Subscriptions choose which events they receive. See Webhooks and the webhook events reference.

Signing secret — the per-subscription secret returned once by POST /webhook_subscriptions. Every delivery is signed with it (X-Cascades-Signature: t=<unix>,v1=<hex HMAC-SHA256>), and rotate_secret replaces it with a 24-hour grace window. See Verify webhook signatures.

Adverse action — the FCRA notice owed to an applicant declined on the basis of a consumer report. In Cascades it is an Action node with action_type: "AdverseAction" that picks the reasons, renders the notice PDF, emails it and archives it, either automatically or as a draft a reviewer sends. See Adverse action and Adverse action notices.

Human review — the branch an IfElse node can route to instead of pass or fail. The execution pauses at status: awaiting_review until a reviewer posts a decision, which resumes pass_steps (approved) or fail_steps (denied). See Human review.

Reference and tooling

MCP server — the Model Context Protocol server that exposes the Cascades API to AI assistants as tools. It is a thin wrapper: every tool is exactly one authenticated REST call using your own API key and scopes. See MCP server.

operationId — the stable identifier of one operation in the OpenAPI spec, such as triggerWorkflow or getExecution. It names the reference page (/docs/api/workflows/trigger-workflow), the generated code samples and the matching MCP tool, and it is the id to quote in error reports. See the API reference and /openapi.json.

OpenAPI spec — the machine-readable contract the reference pages, code samples and MCP manifest are generated from, served at /openapi.json and /openapi.yaml. See the API reference.

Related

• Overview — what the API does and how to integrate, in order
• API reference — every operation, schema, error code and webhook event
• llms.txt — the machine-readable index of these docs