Changelog

This page tracks notable changes to the Fincore API and its documentation: contract updates, behavior changes, new features, deprecations, and operational policies (e.g., webhook delivery/retry rules).

How to read this changelog

Each release may include:

• Type: Added / Changed / Removed / Fixed / Security
• Tags (impact):
  • [Breaking]: requires changes to avoid failures.
  • [Behavior]: not necessarily breaking, but outcomes or rules changed.
  • [Operational]: affects retries, delivery, latency, or runtime expectations.
  • [Docs]: documentation-only changes (no functional change).
  • [Security]: security-related change.

For every entry we aim to include:

• Impact: what changes for you
• Action required: what you should do (if anything)
• References: links to the relevant guide/endpoint

Latest releases

• 2026-05-07: Money Out unified routing: POST /v1/transactions/money_out now automatically detects when the destination instrument belongs to a Finco Pay account and routes the transaction as an internal (book-to-book) transfer. No SPEI is used; settlement is near-real-time. No changes to the request body are required. See Send money to a CLABE and Quickstart.
• 2026-03-13: Private Account Lifecycle: added a new public guide and documented customer-facing lifecycle actions for private accounts, including cancel, block, and activate.
• 2026-03-11: Idempotency: clarified canonical JSON hashing rules and updated deterministic Idempotency-Key generation samples for Python and Node.js.
• 2026-01-28: Internal transactions: clarified MONEY_IN webhook behavior (emitted only when destination belongs to a different owner_id; no webhook for same-owner transfers).
• 2026-01-07: Penny Validation: optional description and external_reference, backend defaults, and webhook propagation.
• 2026-01-05: Auth simplification (JWT primary), client-scoped webhook management, CEP webhook clarifications, changelog launch.

Scope

This changelog may include updates to:

• Guides (Quickstart, Idempotency, Money In, Money Out, Penny Validation, Business Units)
• Webhooks (MONEY_IN, STATUS_UPDATE, CEP)
• OpenAPI specification (fields, schemas, request/response contracts, error models)

If you have questions about a release or need migration help, contact Monato Support: support@monato.com

2026-05-07

Money Out unified routing: automatic internal transfer detection for Finco Pay destination instruments.

This release extends POST /v1/transactions/money_out to automatically detect when the destination instrument belongs to a Finco Pay (Monato) account and route the transaction as an internal book-to-book transfer. No SPEI is used and no changes to the request body are required.

Changed

Money Out unified routing: Changed [Behavior]

Impact: POST /v1/transactions/money_out now handles both external and internal transfers. When the destination instrument belongs to a Finco Pay account, the system routes the transaction as a book-to-book transfer automatically. The subCategory field in the response reflects the routing: SPEI_DEBIT for external, INT_DEBIT for internal.

Action required: None for existing integrations. For new integrations, use POST /v1/transactions/money_out exclusively for all outbound transfers.

References: POST /v1/transactions/money_out, Send money to a CLABE, Internal transfers

Money In webhook, sub_category updated: Changed [Docs]

Impact: INT_CREDIT can originate from POST /v1/transactions/money_out when the destination instrument belongs to a Finco Pay account.

Action required: If your webhook consumer filters on sub_category: INT_CREDIT, no changes are needed. Behavior is the same regardless of the originating endpoint.

References: Webhook MONEY_IN, body.sub_category, Webhook events

Migration notes

1. New integrations
   • Use POST /v1/transactions/money_out for all outbound transfers, both external (SPEI) and internal (Finco Pay).
   • No flags or extra fields needed; routing is automatic based on the destination instrument.

2026-03-13

This release adds a new public Private Account Lifecycle guide and documents the customer-facing lifecycle actions available for private accounts: cancel, block, and activate.

Added

Private Account Lifecycle guide: Added [Docs]

Impact: You now have a dedicated guide that explains the public lifecycle actions supported for private accounts, including their intended usage, supported state transitions, and example requests.

Action required: Review the new guide if your integration needs to temporarily block, reactivate, or permanently cancel private accounts.

References: Private accounts

Cancel a private account endpoint: Added [Behavior] [Docs]

Impact: The public API documentation now includes the endpoint to permanently cancel a private account.

Action required: If you need to permanently disable a private account, use PUT /v1/clients/{clientId}/accounts/{accountId}/cancel.

References: Private accounts, PUT /v1/clients/{clientId}/accounts/{accountId}/cancel

Block a private account endpoint: Added [Behavior] [Docs]

Impact: The public API documentation now includes the endpoint to temporarily block a private account.

Action required: If you need to temporarily disable a private account, use PUT /v1/clients/{clientId}/accounts/{accountId}/block.

References: Private accounts, PUT /v1/clients/{clientId}/accounts/{accountId}/block

Activate a private account endpoint: Added [Behavior] [Docs]

Impact: The public API documentation now includes the endpoint to restore a previously blocked private account to ACTIVE.

Action required: If you need to reactivate a previously blocked private account, use PATCH /v1/clients/{clientId}/accounts/{accountId}/activate.

References: Private accounts, PATCH /v1/clients/{clientId}/accounts/{accountId}/activate

Changed

Quickstart navigation to lifecycle management: Changed [Docs]

Impact: The Quickstart can now direct integrators to the lifecycle management guide after private account creation, making the next operational steps easier to discover.

Action required: None.

References: Quickstart, Private accounts

2026-03-11

Idempotency documentation update: canonical JSON hashing clarification and improved deterministic key generation samples.

This release updates the public Idempotency guide to better explain deterministic Idempotency-Key generation. The guide now clarifies that the request body must be canonicalized before hashing, and it includes clearer reference samples for Python and Node.js.

Fixed

Idempotency canonical JSON hashing clarification: Fixed [Docs]

Impact: The Idempotency guide now explains more precisely how to compute body_hash: the request body must be canonicalized before hashing, with object keys sorted alphabetically at every level and serialized consistently.

Action required: Review your implementation if you generate deterministic Idempotency-Key values client-side, especially in non-Python implementations.

References: Idempotency

Python deterministic key generation sample: Fixed [Docs]

Impact: The Python sample now includes clearer inline comments and step-by-step guidance for generating a deterministic Idempotency-Key. No backend behavior changed.

Action required: None, unless you want to align your implementation with the updated reference example.

References: Idempotency

Node.js deterministic key generation sample: Fixed [Docs]

Impact: The Node.js sample was updated to make the normalization logic clearer and align the example with canonical JSON hashing expectations described in the guide.

Action required: If you implemented the previous sample directly, verify that your body hashing logic produces the same deterministic output for semantically identical payloads, including nested objects.

References: Idempotency

Migration notes

1. Canonicalize the request body before hashing
   • Sort object keys consistently before computing the SHA-256 hash.
   • Ensure semantically identical payloads generate the same body_hash.
2. Keep UUID v5 generation unchanged
   • Continue using:
     • name = client_id + method + body_hash
     • Idempotency-Key = UUIDv5(namespace, name)
3. Validate client-side implementations
   • If you copied a previous example into production code, confirm it matches the canonicalization rules described in the updated guide.

2026-01-28

Documentation updated to clarify when internal transactions emit MONEY_IN (INT_CREDIT) webhooks based on ownership and how to interpret owner_id/sub_category.

This release updates the documentation to clarify webhook emission rules for Money Out and to align the MONEY_IN webhook reference with actual behavior. In short: INT_CREDIT notifications are only emitted for inbound credits to a different owner, while self-transfers do not generate a MONEY_IN webhook event.

Changed

Money Out webhook emission rules: Changed [Docs] [Operational]

Impact: For internal routing through POST /v1/transactions/money_out:

• The API response returns the debit leg (source side).
• The credit leg may trigger a MONEY_IN webhook only when the destination instrument belongs to a different owner_id than the initiator (even if the client_id is the same).
• Self-transfers under the same client_id + owner_id do not generate a MONEY_IN webhook event.
• Documented that dashboard “resend webhook” should be used only when a webhook event exists (self-transfers have nothing to replay).

Action required: If your automation expects MONEY_IN for every internal transfer, update logic to:

• Not expect INT_CREDIT for self-transfers.
• Use the API response and/or transaction reads for self-transfer confirmation and reconciliation.

References: Send money to a CLABE, MONEY_IN webhook event

MONEY_IN webhook reference, internal credits note: Changed [Docs]

Impact: Updated the MONEY_IN webhook documentation to:

• Explicitly state that INT_CREDIT is only emitted for inbound credits to a different owner (not self-transfers).
• Clarify the meaning of owner_id for internal credits (receiving owner).
• Reinforce how to distinguish external vs internal credits using sub_category and payer_institution.

Action required: None. Documentation-only.

References: MONEY_IN webhook event, Send money to a CLABE

2026-01-07

Penny Validation now supports optional description and external_reference with backend defaults and webhook propagation.

This release improves Penny Validation by allowing integrators to send a custom description and external_reference for better traceability. When omitted, the backend applies deterministic defaults. Both fields are propagated to the transaction read endpoint and the CEP webhook payload.

Added

Penny Validation request fields: Added [Behavior]

Impact: POST /v1/transactions/penny_validation now accepts:

• description (optional): string, max 40 chars; letters, numbers and spaces only; special characters not allowed except ñ/Ñ.
• external_reference (optional): numeric string, max 7 digits.

Action required: None. Optional fields only.

References: Validate a bank account

Changed

Penny Validation defaults (backend): Changed [Behavior]

Impact: If optional fields are not provided, the backend sets:

• description → "Validacion de cuenta"
• external_reference → operation date formatted as ddmmaa (e.g. 24/11/2025 → "241125")

Action required: If you relied on empty/missing values, update your expectations to these defaults.

References: Validate a bank account

Propagation to reads and webhook: Changed [Behavior] [Operational]

Impact: description and external_reference are now reflected in:

• GET /v1/clients/{clientId}/transactions/{transactionId}
• CEP webhook payload (e.g., payment_concept, external_reference)

Action required: If you parse/monitor webhook payloads, you can now store these fields for reconciliation and traceability.

References: Validate a bank account

2026-01-05

JWT-first authentication, client-scoped webhooks management, CEP clarification, and Changelog launch.

This release introduces a public Changelog, adds client-scoped webhook management endpoints, and simplifies authentication so that JWT is the primary credential used for API operations.

Added

Public Changelog: Added [Docs]

Impact: You can track API and documentation changes in one place, with daily release notes.

Action required: None.

References: Changelog

Client-scoped Webhooks Management endpoints: Added [Behavior] [Operational]

Impact: You can manage webhooks per client (list, create, retrieve, update, delete) using client-scoped endpoints.

Action required: Prefer the client-scoped endpoints for all webhook operations.

References:

• GET /v1/clients/{clientId}/webhooks: list webhooks for a client
• POST /v1/clients/{clientId}/webhooks: create a webhook for a client
• GET /v1/clients/{clientId}/webhooks/{id}: retrieve a webhook
• PATCH /v1/clients/{clientId}/webhooks/{id}: update a webhook
• DELETE /v1/clients/{clientId}/webhooks/{id}: delete (soft-delete) a webhook

WebhookUpdateRequest schema: Added [Behavior]

Impact: Webhooks can be partially updated (e.g., url, token, webhook_status, optional auth_* fields).

Action required: When updating a webhook, send only the fields you want to change.

References: PATCH /v1/clients/{clientId}/webhooks/{id}

Changed

Authentication simplification (JWT-first): Changed [Behavior] [Operational]

Impact: x-api-key is now bootstrap-only (used to obtain a JWT). After a JWT is issued, API calls should use only Authorization: Bearer <JWT>.

Action required: Stop sending x-api-key on operational API calls; keep it only for JWT bootstrap flows.

References: POST /v1/clients/{clientId}/auth/credential-tokens

CEP webhook clarification for Penny Validation: Changed [Docs] [Operational]

Impact: The CEP webhook is triggered only for Penny Validation transactions (amount = 0.01 MXN). INITIALIZED may appear on API reads but is not emitted by the CEP webhook and should be treated as PENDING.

Action required: Ensure your CEP webhook consumer does not expect INITIALIZED events; treat API-read INITIALIZED as PENDING.

References: Validate a bank account

Migration notes

1. JWT-first auth
   • Use x-api-key to obtain a JWT.
   • Use Authorization: Bearer <JWT> for all subsequent API calls.
2. Webhook creation
   • Use the client-scoped endpoint: POST /v1/clients/{clientId}/webhooks