Reconciliation REST API

Follow the payment. Inspect the proof.

The Flominzo reconciliation REST API reads payment state, events, evidence, positions, settlements, and exceptions in your integration environment.

Last updated: 25 September 2026

Request API access

Start with your integration environment

API access is provisioned as part of an integration. Use the base URL and credentials issued for your environment; this marketing site does not expose a public sandbox or a live payment endpoint.

Protected operations require a bearer token and the appropriate permission. Tokens are scoped to the configured tenant. Keep credentials on your server, out of browser code and public repositories.

Read a payment

Retrieve a payment’s operational and financial view, then follow its event history or query the evidence associated with it.

# Use the API base URL and token issued for your environment.
curl "$FLOMINZO_API_BASE_URL/api/payments/$PAYMENT_ID" \
  --header "Authorization: Bearer $FLOMINZO_ACCESS_TOKEN" \
  --header "Accept: application/json"

Request example. Replace the environment variables with your own values; no credentials are included.

Read endpoints

Method & path	Purpose
`GET /api/payments/open`	Payments still awaiting financial closure.
`GET /api/payments/{id}`	Payment, legs, attempts, evidence, and financial state.
`GET /api/payments/{id}/events`	The payment’s recorded event history.
`GET /api/evidence?paymentId={id}`	Evidence associated with a payment.
`GET /api/evidence?businessDate=YYYY-MM-DD`	Evidence for a business date.
`GET /api/positions`	Current financial positions.
`GET /api/settlements`	Settlement records.
`GET /api/exceptions`	Exceptions requiring investigation.

Decisions require explicit authority

The service also provides permission-controlled operations for exception decisions, resolutions, settlement acceptance, and closing a financial day. These change financial workflow state and must follow the permissions and approval model agreed for your deployment.

Do not infer payment execution endpoints from the product examples on the home page. The examples illustrate the product lifecycle; the exact write contract is supplied during integration.

Build for uncertain outcomes

Check the HTTP response and the returned financial state; a successful read does not prove settlement.
Keep credentials and full financial payloads out of application logs.
Agree retry, timeout, and idempotency behaviour before using any operation that changes state.
Use representative test records and the supported schema for your environment.

Let’s make it specific to you.

Bring your systems, payment flows, and questions. We’ll help define the next step.

Talk to the team