Developers

Build on the control plane.

Submit events, read reconciliation results and act on exceptions programmatically. The API mirrors what operators do in the product, so anything a team does by hand can be automated.

Documentation Talk to us

Illustrative API reference. This website is a product and demonstration interface and is not connected to a live backend. api.concicohq.example is a placeholder host.

01 · API

Four ideas, applied everywhere.

The API is small on purpose. These principles hold across every endpoint.

Resources match the product

Transactions, settlements, reconciliations, exceptions and cases are the same objects operators see in the interface.

Writes are idempotent

Every write accepts an idempotency key, so a retried request cannot create a duplicate record.

Money is a string

Amounts are decimal strings with an explicit currency, never floating-point numbers.

Everything is evented

State changes are delivered as signed webhook events, so integrations react rather than poll.

02 · Authentication

Scoped keys and signed events.

Keys are scoped to a workspace and to the actions they need. Webhook deliveries carry a signature the receiver can verify.

Authenticationillustrative

"# Every request carries a scoped key"
curl https://api.concicohq.example/v1/exceptions \
  -H "Authorization: Bearer $PULSE_API_KEY" \
  -H "Idempotency-Key: $(uuidgen)"

"# Webhook deliveries are signed"
Pulse-Signature: t=1759731249,v1="5257a869e7ecebeda32affa62cdca3fa51cad7e77a0e56ff536d0ce8e108d8bd"

Keys are created per integration and can be revoked without affecting others.
Read-only keys can retrieve results but cannot change state.
Webhook secrets are rotated independently of API keys.
Every API action is attributed to its key in the audit trail.

03 · Example request and response

POST /api/v1/transactions

Submit a transaction, list open exceptions and resolve one. Switch tabs to see each call.

Request

"POST" /api/v1/transactions
Host: api.concicohq.example
Authorization: Bearer "<api_key>"
Idempotency-Key: "5d1c8e0a-9f3b-4a71-8c2e"
Content-Type: application/json

{
  "source": "gateway_b",
  "kind": "payment",
  "amount": "542580.00",
  "currency": "INR",
  "reference": "TXN-48291",
  "occurred_at": "2026-10-05T14:02:11+05:30"
}

Response201 Created

{
  "id": "txn_01HZX48291",
  "status": "accepted",
  "normalized": true,
  "matched": false,
  "expects": [
    { "type": "settlement", "due": "2026-10-06" }
  ]
}

04 · Endpoints

Seven endpoints cover the core loop.

Illustrative endpoints
Method	Path	Purpose
POST	/api/v1/transactions	Submit a transaction event
POST	/api/v1/settlements	Submit a settlement record
GET	/api/v1/reconciliations	List reconciliation results by source
GET	/api/v1/exceptions	List exceptions, filtered by status and severity
GET	/api/v1/exceptions/{id}	Retrieve an exception with its evidence
POST	/api/v1/exceptions/{id}/resolve	Resolve an exception with a reason
POST	/api/v1/webhooks	Register a webhook endpoint

05 · Webhooks and events

Five events to build on.

Illustrative webhook events
Event	Sent when
exception.created	Reconciliation raises a new exception
exception.escalated	A case is escalated to a lead or approver
exception.resolved	A case is resolved with a reason
source.delayed	A connected source falls behind its expected cadence
reconciliation.completed	A reconciliation run for a source finishes

06 · Integration flow

From your service to a resolved case.

A typical integration submits events, listens for exceptions and writes outcomes back to the systems your team already uses.

01SubmitPOST events from your service
02NormalizeMapped to the canonical event
03ReconcileCompared with expectations
04Webhookexception.created delivered
05ActTicket, notification or auto-resolve
06ResolvePOST resolution with reason

Planning an integration?

Tell us which systems you want to connect and we will walk through the API model with you.

Talk to us Explore the platform