pay

Receive cap, trust level and hold window

What the account may receive, how long a new deposit will be held, and what it still needs for the next level — read this BEFORE creating a charge so the amount is never refused and the hold is never a surprise. A deposit that would break the cap answers HTTP 400 account_limit_exceeded with the same numbers in error.details. The cap and the hold are independent: vault_window_hours: 0 with cap.enforced: true means charges are refused above the cap and nothing is held below it. Deliberately omits which risk rule fired and every threshold: a caller learns that a limit exists, never the map around it.

get/api/vault/status

Request

  • Base URL: https://api.depixapp.com
  • URL: https://api.depixapp.com/api/vault/status
  • Auth: HTTP bearer

Response

Current position in the hold policy.

vault_activeboolean required

false when the whole mechanism is switched off — every number below is then informational only and deposits settle on the pre-Cofre rules. true does NOT by itself mean deposits are held: the receive cap and the hold window are independent switches, and vault_window_hours is the one that says whether this account waits.

policy_versionstring required

Version of the policy that produced these numbers. Every deposit records the version that decided its own deadline.

vault_window_hoursinteger required

Hours a new deposit will wait before converting, at the current level. 0 means no hold is added — either the whole mechanism is off, or the hold window is off while the receive cap keeps being enforced (vault_active: true with cap.enforced: true). Read this field, not vault_active, before telling anyone their money will wait. It never reports the pre-existing per-account delays, which are outside this mechanism.

Changes

No recorded changes to this operation across all 1 revision of this API.