Credit limit ( credit_limit )

Role

The credit limit bounds buyer risk in deferred B2B flows. It is compared with the buyer's receivable to trigger alerts (credit_limit.approaching) or block new transactions (credit_limit.exceeded). It is also used in orchestration processes to decide whether to approve or decline a credit request.

The multi-source model represents decisions from different actors — merchant, credit insurer, BNPL provider — and combines them according to each flow's business logic.

Identifier and structure

Each credit limit has a stable identifier prefixed with crl_.

{
"object": "credit_limit",
"id": "crl_5f3a2e9b1c8d4f7e",
"buyer_id": "cmp_3a8f1d9c2b4e7f6a",
"merchant_id": "mer_1a2b3c4d5e6f7a8b",
"amount_excluding_tax": 50000000,
"amount_including_tax": null,
"currency": "eur",
"source": "credit_insurer",
"source_reference": "CREDIT-GUARANTEE-2026-00512",
"metadata": {},
"valid_from": "2026-01-01",
"valid_until": "2026-12-31",
"active": true,
"created_at": "2026-01-10T09:00:00.000Z",
"updated_at": "2026-01-10T09:00:00.000Z"
}

Fields

At least one of the two amounts (amount_excluding_tax or amount_including_tax) is required at creation. Both can be supplied simultaneously. The basis selected at calculation time determines which one is used.

Source

The source field identifies who made the decision to grant this limit. The same buyer may have one limit per source, all active at the same time.

Validity and activation

A credit limit contributes to calculations only when it is active: true and the current date falls within the [valid_from, valid_until] window. Both bounds are inclusive; a null bound means no constraint on that side.

Setting active: false immediately disables the limit without deleting it, preserving decision history. A disabled limit remains accessible through the API but is no longer considered by receivable monitoring or effective-limit resolution.

Effective limit

When a buyer has several active limits — multiple sources or several decisions from one source — the platform combines them through the resolution endpoint.

GET /v1/credit-limits/effective
?merchant_id=mer_1a2b
&buyer_id=cmp_3a8f
&currency=eur
&strategy=maximum
&basis=excluding_tax
&sources=merchant,credit_insurer
&at=2026-06-17

{
"object": "effective_credit_limit",
"merchant_id": "mer_1a2b",
"buyer_id": "cmp_3a8f",
"currency": "eur",
"at": "2026-06-17",
"strategy": "maximum",
"basis": "excluding_tax",
"sources": ["merchant", "credit_insurer"],
"amount": 50000000,
"amount_excluding_tax": 50000000,
"amount_including_tax": null,
"selected_credit_limit_id": "crl_5f3a2e",
"selected_credit_limit_ids": ["crl_5f3a2e"],
"candidates": [
  {
    "id": "crl_5f3a2e",
    "source": "credit_insurer",
    "amount": 50000000
  }
]
}

Resolution strategies

The basis field (excluding_tax or including_tax) determines which amount is used for comparison and returned in amount. Every candidate limit must have the amount corresponding to the selected basis to be retained.

In processes

credit.add_credit_limit

Creates a new credit limit for a company. Useful for recording a credit-insurer decision received through a webhook or form.

Main parameters

{
"company": "platform.company",
"basis": "excluding_tax",
"amount": 50000000,
"currency": "eur",
"source": "credit_insurer",
"source_reference": "CREDIT-GUARANTEE-2026-00512",
"valid_from": "2026-01-01",
"valid_until": "2026-12-31"
}

Output

{
"credit_limit": "platform.credit_limit"
}

credit.evaluate_credit_availability

Router node combining effective-limit resolution, current-exposure calculation, and the approval decision in one step. This is the recommended entry point for capacity checks in a credit-request process.

Parameters

{
"company": "platform.company",
"currency": "eur",
"basis": "excluding_tax",
"strategy": "maximum",
"requested_amount": 10000000
}

The node selects the route approved or rejected.

Outputs

{
"effective_credit_limit": "platform.effective_credit_limit",
"credit_exposure": "platform.credit_exposure",
"credit_availability_check": "platform.credit_availability_check"
}

Individual nodes

The three steps of credit.evaluate_credit_availability are also available separately for greater flexibility:

Events

credit_limit.updated is emitted both at creation and on every modification — there is no credit_limit.created distinct.

credit_limit.exceeded and credit_limit.approaching are emitted when the receivable snapshot is refreshed, only when the buyer has an active limit. See the receivable documentation for trigger details and suspension logic.