API reference · Pricing, reporting & reconciliation

Reconciliation deliveries

POST/reconciliation/entity/{code}/channel/{channelKey}/deliveryDeliver a signed statement file
POST/reconciliation/entity/{code}/channel/{channelKey}/webhookDeliver a webhook body
GET/reconciliation/entity/{code}/ingestionsList an entity's ingestions

POST Deliver a signed statement file

POST /reconciliation/entity/{code}/channel/{channelKey}/delivery

The detached signature is checked over the whole file before a byte of it is parsed, and a file that does not verify is stored in quarantine with the reason named rather than read to see what it claims - a parser is an attack surface and an unverified delivery is somebody else's input. Delivering identical bytes twice produces one ingestion: a finance team that cannot tell whether an upload worked uploads it again, and that is correct behaviour. A 200 here means accepted, not reconciled - the response says whether it verified, whether it was a duplicate, and if it was quarantined, why.

Headers

Name	Notes
`Authorization`	Bearer token
`X-Tenant`	Your tenant
`X-Environment`	test or live
`Content-Type`	multipart/form-data

Path parameters

Name
`code`
`channelKey`

Query parameters

Name	Default
`keyId`	Optional
`signature`	Optional
`periodStart`	Optional
`periodEnd`	Optional
`statementSequence`	Optional
`declaredRowCount`	Optional
`declaredOpeningBalance`	Optional
`declaredClosingBalance`	Optional
`declaredTotalCredits`	Optional
`declaredTotalDebits`	Optional

Example

Request body: object · Response: GenericResponseDeliveryResponse

curl -X POST "https://api.bridgemoni.com/reconciliation/entity/value/channel/value/delivery" \
  -H "Authorization: Bearer $BRIDGEMONI_TOKEN" \
  -H "X-Tenant: $BRIDGEMONI_TENANT" \
  -H "X-Environment: $BRIDGEMONI_ENV" \
  -F "file=@./document.pdf"

{
  "data": {
    "reference": "b3f1c2d4-5e6a-4b7c-8d9e-0f1a2b3c4d5e",
    "entityCode": "string",
    "channelKey": "string",
    "contentHash": "string",
    "sizeBytes": 0,
    "status": "string",
    "acceptedRowCount": 0,
    "rejectedRowCount": 0,
    "statementProfileCode": "string",
    "statementProfileVersion": 0,
    "rejectionReason": "string",
    "duplicate": true,
    "quarantined": true,
    "failureKind": "string",
    "signatureKeyId": "string",
    "signatureVerifiedAt": "string",
    "documentReference": "b3f1c2d4-5e6a-4b7c-8d9e-0f1a2b3c4d5e"
  },
  "description": "Delivery accepted"
}

Responses

Status	When
`200`	Delivery accepted

POST Deliver a webhook body

POST /reconciliation/entity/{code}/channel/{channelKey}/webhook

The HMAC is verified against the exact bytes that arrived, never against the body re-serialised from a parsed object - re-serialising first means the signature covers something the sender never sent, which turns verification into decoration. The signature carries a timestamp and a body outside the channel's freshness window is quarantined as a replay: a signature with no freshness bound can be replayed forever. A stream like this is always contributing and never authoritative, because nothing in it says how many events there should have been.

Headers

Name	Notes
`Authorization`	Bearer token
`X-Tenant`	Your tenant
`X-Environment`	test or live
`X-Reconciliation-Signature`
`Content-Type`	application/json

Path parameters

Name
`code`
`channelKey`

Example

Request body: string · Response: GenericResponseDeliveryResponse

curl -X POST "https://api.bridgemoni.com/reconciliation/entity/value/channel/value/webhook" \
  -H "Authorization: Bearer $BRIDGEMONI_TOKEN" \
  -H "X-Tenant: $BRIDGEMONI_TENANT" \
  -H "X-Environment: $BRIDGEMONI_ENV" \
  -H "Content-Type: application/json" \
  -d '"string"'

"string"

{
  "data": {
    "reference": "b3f1c2d4-5e6a-4b7c-8d9e-0f1a2b3c4d5e",
    "entityCode": "string",
    "channelKey": "string",
    "contentHash": "string",
    "sizeBytes": 0,
    "status": "string",
    "acceptedRowCount": 0,
    "rejectedRowCount": 0,
    "statementProfileCode": "string",
    "statementProfileVersion": 0,
    "rejectionReason": "string",
    "duplicate": true,
    "quarantined": true,
    "failureKind": "string",
    "signatureKeyId": "string",
    "signatureVerifiedAt": "string",
    "documentReference": "b3f1c2d4-5e6a-4b7c-8d9e-0f1a2b3c4d5e"
  },
  "description": "Delivery accepted"
}

Responses

Status	When
`200`	Delivery accepted

GET List an entity's ingestions

GET /reconciliation/entity/{code}/ingestions

One row per distinct delivery, newest first, with the key that verified it. A delivery re-sent with identical bytes does not appear twice.

Headers

Name	Notes
`Authorization`	Bearer token
`X-Tenant`	Your tenant
`X-Environment`	test or live

Path parameters

Name
`code`

Example

Response: GenericResponseListDeliveryResponse

curl -X GET "https://api.bridgemoni.com/reconciliation/entity/value/ingestions" \
  -H "Authorization: Bearer $BRIDGEMONI_TOKEN" \
  -H "X-Tenant: $BRIDGEMONI_TENANT" \
  -H "X-Environment: $BRIDGEMONI_ENV"

{
  "data": [
    {
      "reference": "b3f1c2d4-5e6a-4b7c-8d9e-0f1a2b3c4d5e",
      "entityCode": "string",
      "channelKey": "string",
      "contentHash": "string",
      "sizeBytes": 0,
      "status": "string",
      "acceptedRowCount": 0,
      "rejectedRowCount": 0,
      "statementProfileCode": "string",
      "statementProfileVersion": 0,
      "rejectionReason": "string",
      "duplicate": true,
      "quarantined": true,
      "failureKind": "string",
      "signatureKeyId": "string",
      "signatureVerifiedAt": "string",
      "documentReference": "b3f1c2d4-5e6a-4b7c-8d9e-0f1a2b3c4d5e"
    }
  ],
  "description": "Ingestions retrieved successfully"
}

Responses

Status	When
`200`	Ingestions retrieved successfully

Generated from the OpenAPI document. Branch on the HTTP status: there is no machine-readable error code on the wire. Errors