@codespar/sdk 0.16.1 → 0.16.2

package/dist/generated/openapi.d.ts

@@ -13998,6 +13998,11 @@ export interface paths {
                             merchant_pin_kind?: "pix-key" | "merchant-id" | "mcc";
                             withdrawal_allowlist?: string[];
                             dda_allowlist?: string[];
+                            periodic_cap?: {
+                                /** @enum {string} */
+                                window: "day" | "month";
+                                cap_minor: number;
+                            };
                             slots?: {
                                 /** @enum {string} */
                                 currency: "BRL" | "USD" | "MXN" | "COP" | "ARS" | "USDC" | "BRLA";
@@ -14130,6 +14135,11 @@ export interface paths {
                             merchant_pin_kind?: "pix-key" | "merchant-id" | "mcc";
                             withdrawal_allowlist?: string[];
                             dda_allowlist?: string[];
+                            periodic_cap?: {
+                                /** @enum {string} */
+                                window: "day" | "month";
+                                cap_minor: number;
+                            };
                             slots?: {
                                 /** @enum {string} */
                                 currency: "BRL" | "USD" | "MXN" | "COP" | "ARS" | "USDC" | "BRLA";
@@ -14347,7 +14357,7 @@ export interface paths {
          *     - `hosted` — the consumer's browser submits from our page. `attestation` is REFUSED (400 `attestation_not_accepted`): our page witnessed the act, and the IP and user-agent on the consent record are the consumer's.
          *     - `partner` — your server submits. `attestation` is REQUIRED (400 `attestation_required`): the IP and user-agent recorded are your server's, so the only statement about the human is yours. It is signed into the mandate as `consent_attestation` and cannot be edited afterwards without breaking the signature.
          *
-         *     `attestation.method` says how the human authorized: `partner_session` (an authenticated session in your product), `in_person`, or `verified_code` (a code YOU issued and verified). `asserted_at` is the instant you say they authorized, in Unix seconds. `reference` is your own record id, `[A-Za-z0-9_-]{1,120}`, and never personal data — it is joined into the signed string, so the character set is the schema's, not a suggestion.
+         *     `attestation.method` says how the human authorized: `partner_session` (an authenticated session in your product), `in_person`, `verified_code` (a code YOU issued and verified), or `partner_biometric` (YOU ran a biometric check at the moment of the act). `partner_biometric` is not a flavour of `partner_session`: in a dispute a session says someone was logged in and a biometric says a body was present. We capture and verify no biometric ourselves — this records what YOU assert, sealed by the mandate signature so it cannot be edited afterwards; the evidence behind it stays with you. `asserted_at` is the instant you say they authorized, in Unix seconds. `reference` is your own record id, `[A-Za-z0-9_-]{1,120}`, and never personal data — it is joined into the signed string, so the character set is the schema's, not a suggestion.
          */
         post: {
             parameters: {
@@ -14368,7 +14378,7 @@ export interface paths {
                         display_label?: string;
                         attestation?: {
                             /** @enum {string} */
-                            method: "partner_session" | "in_person" | "verified_code";
+                            method: "partner_session" | "in_person" | "verified_code" | "partner_biometric";
                             asserted_at: number;
                             reference?: string;
                         };
@@ -25641,7 +25651,7 @@ export interface paths {
          *
          *     Every field carries its provenance in `from`. Amounts are integer centavos (`*_minor`). `rail_quote` is refused by name: the amount and the payee of a payment come from the rail, never from a request. `attribution.credential_id` is set to the API key the request authenticated with; a different value is refused.
          *
-         *     **Every payable this endpoint creates is `NEEDS_REVIEW` for now.** The amount, payee and due-date checks (`amount_matches_rail`, `beneficiary_document_matches_supplier`, `due_date_state`, and `pix_key_owner_matches_supplier` when the payable carries a Pix BR Code) always block `READY`, because the amount and the payee of a payment come from the payment rail, and the rail consult is not wired to this endpoint yet. They appear in `review.review_by` with cause `required_not_implemented`. No check can be left without an answer in this release, so `VALIDATING` is not returned either.
+         *     **The amount and the payee come from the rail, never from what was sent.** `amount_matches_rail`, `beneficiary_document_matches_supplier` and `due_date_state` run against a consult of the boleto on the payable, and they block `READY` whether or not they answered. A consult that could not be made — no connected payment provider, a provider that did not answer — leaves them `indisponivel` and the payable `NEEDS_REVIEW`, named under `review.review_by`. `pix_key_owner_matches_supplier` is not consulted in this release and blocks a payable carrying a Pix BR Code with cause `required_not_implemented`. `VALIDATING` is never returned: nothing re-runs a validation yet, so a check with no answer goes to a person rather than waiting.
          *
          *     **Status.** Two fields answer two questions. `review.validation_status` is what the checks alone say: `REJECTED` (a check that rejects failed), `NEEDS_REVIEW` (a check failed, or a required check has no answer it can have), `VALIDATING` (a required, implemented check did not answer and will be retried) or `VALIDATED` (every required check passed). `status` is what the payable may do: `READY` only from `VALIDATED` with no review trigger open, and `NEEDS_REVIEW` when a trigger is open. The trigger this API evaluates is `new_supplier`: this project has no executed payable for the supplier's document, or the payable names no supplier document. It is evaluated per project, never across projects.
          *
@@ -26818,7 +26828,7 @@ export interface paths {
         };
         /**
          * Read a payable
-         * @description The payable, its `status`, the outcome of every check in `validation`, and why it has that status in `review`. Reading never re-runs a check or changes the status. **Every payable this endpoint creates is `NEEDS_REVIEW` for now.** The amount, payee and due-date checks (`amount_matches_rail`, `beneficiary_document_matches_supplier`, `due_date_state`, and `pix_key_owner_matches_supplier` when the payable carries a Pix BR Code) always block `READY`, because the amount and the payee of a payment come from the payment rail, and the rail consult is not wired to this endpoint yet. They appear in `review.review_by` with cause `required_not_implemented`. No check can be left without an answer in this release, so `VALIDATING` is not returned either.
+         * @description The payable, its `status`, the outcome of every check in `validation`, and why it has that status in `review`. Reading never re-runs a check or changes the status. **The amount and the payee come from the rail, never from what was sent.** `amount_matches_rail`, `beneficiary_document_matches_supplier` and `due_date_state` run against a consult of the boleto on the payable, and they block `READY` whether or not they answered. A consult that could not be made — no connected payment provider, a provider that did not answer — leaves them `indisponivel` and the payable `NEEDS_REVIEW`, named under `review.review_by`. `pix_key_owner_matches_supplier` is not consulted in this release and blocks a payable carrying a Pix BR Code with cause `required_not_implemented`. `VALIDATING` is never returned: nothing re-runs a validation yet, so a check with no answer goes to a person rather than waiting.
          *
          *     **Status.** Two fields answer two questions. `review.validation_status` is what the checks alone say: `REJECTED` (a check that rejects failed), `NEEDS_REVIEW` (a check failed, or a required check has no answer it can have), `VALIDATING` (a required, implemented check did not answer and will be retried) or `VALIDATED` (every required check passed). `status` is what the payable may do: `READY` only from `VALIDATED` with no review trigger open, and `NEEDS_REVIEW` when a trigger is open. The trigger this API evaluates is `new_supplier`: this project has no executed payable for the supplier's document, or the payable names no supplier document. It is evaluated per project, never across projects.
          *