Skip to main content
This walkthrough takes you end-to-end through ReconLayer’s core loop: tell ReconLayer what payment you expect (a payment intent), submit evidence of what actually happened (provider evidence), and read back the reconciliation outcome (a reconciliation case). All examples use ReconLayer’s public API base URL.
1

Get an API key

API keys are created from the dashboard by a signed-in user (or via POST /v1/api-keys with a Clerk session token — this endpoint requires a signed-in dashboard session, not another API key).
201 Created
plaintextKey is returned once. Copy it now — ReconLayer stores only its hash and cannot show it again. If you lose it, revoke the key and create a new one.
Export it for the rest of this walkthrough:
From here on, every request authenticates with this key alone — the API key resolves your organization, so you don’t need x-organization-id. See Authentication for the full credential model.
2

Create a payment intent

A payment intent tells ReconLayer what you expect to happen for a transfer — the canonical “what should occur” record that evidence is later reconciled against.This is a write endpoint, so it requires an Idempotency-Key header. Generate a fresh UUID before your first attempt and reuse it on any retry — see Idempotency.
201 Created
Save paymentIntentId and caseId — you’ll use them in the next steps.
outcome is "created" the first time ReconLayer sees this externalReference. If you retry with a new Idempotency-Key but the same externalReference and matching fields, ReconLayer returns the existing payment intent with "outcome": "reused" and a 200 instead of creating a duplicate. If the fields don’t match, you get 409 payment_intent_conflict. See API Design Principles.
Full reference: POST /v1/payment-intents.
3

Submit provider evidence

Once a payment intent exists, submit evidence describing what actually happened on the rail — for example, a confirmed transfer reported by your provider. ReconLayer’s matcher reconciles this evidence against the payment intent’s expected legs.This is also a write endpoint and requires its own Idempotency-Key.
201 Created
matchedCaseIds tells you which reconciliation case(s) this evidence was matched against — in this walkthrough, the case created alongside your payment intent in step 2.Full reference: POST /v1/evidence/provider. For on-chain transfer evidence, see POST /v1/evidence/onchain.
4

Fetch the reconciliation case

Read back the reconciliation outcome using the caseId from step 2 (or a matchedCaseId from step 3 — they’re the same case in this walkthrough).
200 OK
reconciliationStatus: "reconciled" and verdict: "matched" confirm the evidence you submitted in step 3 satisfied the expectation created in step 2.If the amounts didn’t line up, reconciliationStatus would be "unreconciled" and unexplainedDelta would carry the difference — that’s an exception for your team (or automation) to investigate.Full reference: GET /v1/reconciliation-cases/{caseId}. To list and filter cases in bulk, see GET /v1/reconciliation-cases.

​
What’s next

  • API Design Principles — idempotency, business-level uniqueness, and route conventions in depth.
  • Idempotency — the Idempotency-Key contract used in steps 2 and 3.
  • Errors — what 400/404/409/429 responses look like and how to handle them.
  • Pagination — listing payment intents and reconciliation cases at scale.
  • Rate limits — request limits and backoff guidance.
  • Authentication — the full credential and organization-resolution model.