Sign in to run requests with your own sandbox key. Sign in

Guides

Your first screening

Step by step from a fresh sandbox key to a decided execution — trigger a test subject, pick the mock outcome, poll, handle review, and read the notice.

This guide runs one applicant through a cascade end to end in the sandbox: pick a registered test subject for a realistic payload, choose the mock outcome, trigger, poll, decide a human review if the cascade pauses, and read what came out. Everything is execution_mode: test, so nothing is billed and no bureau is called.

  1. Pick the cascade and a test subject

    List your cascades and note an id. Then ask for the subjects registered for that cascade's products — each comes with a payload shaped for the trigger endpoint:

    cURL
    curl "https://cascades.crscreditapi.com/api/v1/workflows/27/test_cases" \
      -H "Authorization: Bearer {{API_KEY}}"

    Pick any subject. When the subject is registered for every product node in your cascade, the test run replays its authored history (a borderline credit file, a criminal record, an eviction) at no charge, and input_context.sandbox_replay is true; otherwise every product node returns its schema mock. See Test identities. If the list is empty the registry could not be reached or the cascade has no covered products; any hand-written applicant works just as well in test mode.

  2. Trigger the run

    Send the subject's payload as the trigger body with a unique Idempotency-Key (use your own application id) and an external_reference you can correlate on later:

    cURL
    curl -X POST "https://cascades.crscreditapi.com/api/v1/workflows/27/trigger" \
      -H "Authorization: Bearer {{API_KEY}}" \
      -H "Content-Type: application/json" \
      -H "Idempotency-Key: 3fa85f64-5717-4562-b3fc-2c963f66afa6" \
      -d '{
        "payload": {
          "applicant": {
            "first_name": "Jordan",
            "last_name": "Lee",
            "email": "jordan@example.com"
          }
        },
        "execution_mode": "test",
        "external_reference": "rv-app-20491"
      }'

    For an applicant that is not a replayed subject, every product node returns its clean happy_path mock by default and the applicant is approved. To walk the decline path in test mode, add "scenario": "fail_path" to payload — every product node then returns its decline mock (the eviction node, for example, reports two filings and recommendation: FAIL):

    JSON
    {
      "payload": {
        "scenario": "fail_path",
        "applicant": { "first_name": "Raymond", "last_name": "Okafor", "ssn": "…", "dob": "1982-01-01" },
        "property": { "address": "1803 Norma", "city": "Cottonwood", "state": "CA", "zip": "91502" }
      },
      "execution_mode": "test",
      "external_reference": "rv-app-20493"
    }

    Expect 202 Accepted. Keep data.id — that is the execution — and meta.request_id for support.

    Try it

    POST /workflows/{id}/trigger

    Sign in to run this against your sandbox — the console uses a key that only ever runs in test mode.

    Sign in to try it
  3. Poll until it settles

    Poll every second or two until status is completed, failed, cancelled, skipped, or awaiting_review:

    cURL
    curl "https://cascades.crscreditapi.com/api/v1/executions/1842" \
      -H "Authorization: Bearer {{API_KEY}}"

    With executions:read:full the response includes step_outputs: one entry per node, keyed by node id, holding the report fields the decision used (for the credit subject, creditScore.fico9 and the inquiry counts) and which branch each IfElse took.

    JSON
    {
      "status": "completed",
      "step_outputs": {
        "credit": { "creditScore.fico9": 660, "summary.recentInquiries": 0, "recommendation": "PASS" },
        "decide": { "matched_branch": "pass", "conditions": [{ "field": "creditScore.fico9", "operator": "greater_than_or_equal", "value": 640, "result": true }] },
        "approve": { "decision": "approved" }
      }
    }
  4. If it pauses: decide the review

    A cascade with a human-review branch stops at awaiting_review. Approve or deny it — in test mode the branch runs inline and the response is the final state:

    cURL
    curl -X POST "https://cascades.crscreditapi.com/api/v1/executions/1842/review_decisions" \
      -H "Authorization: Bearer {{API_KEY}}" \
      -H "Content-Type: application/json" \
      -d '{
        "decision": "approved",
        "note": "Manual review confirmed; OFAC clean."
      }'

    approved continues down pass_steps; denied continues down fail_steps; an adverse-action node in human_review_steps prepared its notice draft when the run was flagged. The whole decision trail is at GET /executions/{id}/review_events. More in Handle human review.

  5. Read the artifacts

    If the cascade pulled a credit report, its PDF is listed at GET /executions/{id}/report_artifacts; if it declined the applicant with an adverse-action node, the notice PDFs are at GET /executions/{id}/notice_artifacts. Listing needs executions:read; downloading a file needs executions:read:full.

    cURL
    curl "https://cascades.crscreditapi.com/api/v1/executions/1842/notice_artifacts" \
      -H "Authorization: Bearer {{API_KEY}}"

Where to go from here

  • Replace polling with a webhook subscription — execution.completed arrives seconds after the transition.
  • Run many applicants at once with a batch.
  • When your account is approved, flip execution_mode to live: Sandbox vs live.
Was this page helpful?