Reconciliation examples

Documentation status

Last verified: 26 Sep 2026. Follow the status vocabulary.

Money ingestion

POST /v1/ingestion/background with session_id, tenant_id, partner_id, gl_file_url[], bank_file_url[], on_existing_action.

Success: 2xx accepting the session. Completion: not the HTTP response alone — watch pipeline status / matches.

Asset ingestion

POST /v1/ingestion/asset — asset/holdings session. Consumers of software/matched records: asset event contract.

Exception detection

Detection runs automatically: the reconciliation engine calls the exception service's detect routes after matching. The detect routes are internal; do not call them.

Exception resolution

The body below is the same on the primary Pub/Sub request topic and on the manual testing / fallback route POST /v1/exceptions/resolve:

{
  "resolution_request_id": "res-001",
  "partner_id": "YOUR_PARTNER_ID",
  "tenant_id": "YOUR_TENANT_ID",
  "decision": "approved",
  "customer_type": "mfb",
  "cluster_type": "amount_mismatch",
  "note": "Reviewed by ops"
}

customer_type must be mfb or commercial_bank (the latter also needs service). A 200 from the HTTP route can still contain success: false entries: check results[].success. Full field list: exception resolve contract.

Duplicate handling

Situation	Behaviour
Same pipeline trigger for same session within guard window	Duplicate trigger ignored
Rerun after failure	Prefer a new session_id
Same resolution_request_id	Idempotent on the Pub/Sub path (atomic claim). On HTTP, send your own id; a missing id is replaced with a random one

Status / completion

GET /v1/loader/pipeline-status/{session_id} — interpret stage and terminal success/failure. Unmatched remaining after “complete” is normal until exceptions are resolved.

See product semantics.