Reconcile every transaction, automatically.

Cascade ingests transaction feeds from banks, processors, and your own ledger, matches them against configurable rules, and surfaces the ones that don't line up — so your team investigates exceptions instead of spreadsheets.

Cascade is API-first. Everything the console does is available over the REST API and CLI, so reconciliation can live inside your close process, your data warehouse, or an operations dashboard your team already uses.

Pick a path

How it fits together

Three concepts carry through every page of these docs:

• Sources are the feeds you connect — a bank statement, a processor settlement file, an internal ledger export.
• Matching rules decide which records from two sources represent the same real-world transaction, using match keys and tolerances you control.
• Breaks are what's left over: records that should have matched but didn't, or matched outside tolerance. Resolving breaks is the daily work Cascade is built to shrink.

Installation & deployment

Two supported paths: managed SaaS for teams who want to start immediately, and self-hosted for teams with data-residency or network requirements. Both reach a working reconciliation in roughly ten minutes.

Option A — Managed SaaS

Nothing to install. Create a secret key, point the CLI at your organization, and confirm connectivity.

npm install -g @cascade/cli
cascade auth login --key sk_live_••••••••

cascade status

# ✓ authenticated as acme-payments (org_9F2k)
# ✓ api v1 · region us-east · latency 41ms

Option B — Self-hosted (Docker)

Cascade self-hosts as four services: the API, the matching worker, PostgreSQL, and Redis. The compose file below runs all four on one host for evaluation. For production, see sizing below.

services:
  api:
    image: cascade/api:1.8
    ports: ["8080:8080"]
    environment:
      CASCADE_DB_URL: postgres://cascade:secret@db:5432/cascade
      CASCADE_REDIS_URL: redis://cache:6379
      CASCADE_SECRET_KEY: ${CASCADE_SECRET_KEY}
    depends_on: [db, cache]
  worker:
    image: cascade/worker:1.8
    environment:
      CASCADE_DB_URL: postgres://cascade:secret@db:5432/cascade
      CASCADE_REDIS_URL: redis://cache:6379
    depends_on: [db, cache]
  db:
    image: postgres:16
    environment:
      POSTGRES_USER: cascade
      POSTGRES_PASSWORD: secret
  cache:
    image: redis:7

export CASCADE_SECRET_KEY=$(openssl rand -hex 32)
docker compose up -d

docker compose exec api cascade-migrate up

curl -s localhost:8080/healthz

{
  "status": "ok",
  "checks": { "db": "ok", "redis": "ok", "worker": "ok" }
}

Production sizing

Next

With Cascade running, connect your first two sources and then author a matching rule →

Author a matching rule

A matching rule tells Cascade which records from two sources represent the same transaction. This guide builds a rule that matches a bank feed to your ledger on reference and amount, allows a small fee tolerance, and backtests it before it touches live data.

"tolerance": {
  "field": "amount",
  "absolute": 10.00,
  "percent": 0.5,
  "apply": "min"
}

cascade rules backtest rule_draft_8830 --window 30d

# matched      18,204  (96.1%)
# breaks          742  (3.9%)
#   amount out of tolerance   611
#   no candidate               131

cascade rules publish rule_draft_8830
# ✓ published as rule_ach_ledger_v1 · effective now

Next: when breaks appear, work them from the Breaks API → or diagnose a stubborn one with Why didn't these match? →

Breaks & authentication

The Cascade REST API is organized around resources, uses predictable HTTP verbs, and returns JSON with conventional status codes. This page covers authentication, request conventions, and the Breaks resource in full.

Authentication

Authenticate every request with a secret key in the Authorization header. Keys are environment-scoped: sk_live_ for production data and sk_test_ for the sandbox. Requests over plain HTTP are rejected.

curl https://api.cascade.dev/v1/breaks \
  -H "Authorization: Bearer sk_live_••••••••"

Request conventions

List breaks

Returns a paginated list of breaks, most recent first. Filter by status, source, or the reconciliation run that produced them.

Query parameters

Request

curl "https://api.cascade.dev/v1/breaks?status=open&limit=2" \
  -H "Authorization: Bearer sk_live_••••••••"

Response

{
  "object": "list",
  "has_more": true,
  "data": [
    {
      "id": "brk_3aQ7x2Lp",
      "object": "break",
      "status": "open",
      "reason": "amount_out_of_tolerance",
      "amount": 3297.00,
      "currency": "usd",
      "residual": 7.00,
      "left":  { "source": "bank_ach", "ref": "ACH-4472" },
      "right": { "source": "ledger",  "ref": "INV-2233" },
      "run_id": "run_88b1",
      "created": 1751760000
    }
  ]
}

Resolve a break

Marks a break resolved with a reason code and optional note. Send an Idempotency-Key so a retried request doesn't double-post an audit entry.

curl https://api.cascade.dev/v1/breaks/brk_3aQ7x2Lp/resolve \
  -H "Authorization: Bearer sk_live_••••••••" \
  -H "Idempotency-Key: 7c1e-resolve-2233" \
  -d resolution=fee_adjustment \
  -d note="Processor fee, within policy"

Webhook events

Subscribe to events instead of polling. Cascade signs each delivery with an HMAC in the Cascade-Signature header; verify it before trusting the payload.

Errors

Cascade uses conventional HTTP status codes and returns a machine-readable error object. type is stable and safe to branch on; message is for humans and may change.

Why didn't these transactions match?

This is the question every reconciliation team asks first. Work top to bottom — the branches are ordered by how often each cause is the real one. Each ends with the fix and where to make it.

Still stuck?

Pull the run's decision log — it records, per record, which rule evaluated it and why the best candidate was rejected. That log is the ground truth when the console view isn't enough.

cascade runs explain run_88b1 --record ACH-4472

# candidate INV-2233 rejected: amount 3297.00 vs 3290.00
# residual 7.00 exceeds tolerance (min of $10 / 0.5% = $6.45)

This example break failed by 55 cents of tolerance headroom — a textbook case for branch one above.

How this documentation was made

This sample was produced with an AI-augmented, docs-as-code workflow. AI accelerated drafting and quality control; a human owned information architecture, technical correctness, and every contract-level detail. This page documents that division of labor honestly, because being able to defend it is the point.

The pipeline

Where the line sits

The short version: AI made the writing faster; it did not make the writer optional.

Portfolio notice

This is a writing sample, not real product documentation.

Cascade is a fictional product created solely to demonstrate technical writing across a realistic documentation surface: an overview, installation and deployment, a task-based user guide, an API reference, and a troubleshooting diagnostic. Any resemblance to a real company or product is coincidental.

All endpoints, keys, hostnames, and identifiers shown here are invented and non-functional. api.cascade.dev and app.cascade.dev do not exist; the code samples illustrate documentation conventions and will not run.

The sample was produced with the AI-augmented workflow described under How this documentation was made. It is offered as evidence of documentation craft — information architecture, task analysis, API reference discipline, and diagnostic design — and of a defensible, transparent way of working with AI in the authoring loop.

Prepared as a portfolio piece. Available to walk through the reasoning behind any page on request.