APICambios
Cambios de la API por fecha, con su clasificación.
Aquí se publica todo cambio del contrato. Suscríbete al RSS. Cada entrada está clasificada como Nuevo, Mejora, Corrección, Obsoleto o Cambio incompatible.
2026-11-06 · Corrección
Un monto de entrada en cero (0, 0.0, 0.00) responde 400 invalid_request en pagos, cotizaciones y cobros, en live y en sandbox. No abre operación ni consume cupo. Si max_source_amount o destination_amount van, también deben ser mayores que cero.
2026-11-06 · Mejora
Los pagos tienen un tope acumulado por empresa, por día natural de México y por días corridos. Rebasarlo responde 422 limit_exceeded con retryable: false. Los valores y cómo se cuenta están en Límites. max_amount sigue en null: no hay tope por pago.
2026-11-05 · Mejora
Movement y Receipt traen payment_id y external_ref: el movimiento dice de qué pago de esta API sale. En webhooks, el código de estado decide: cualquier 2xx es éxito, y FITAL cierra la conexión al recibirlo. Deduplica por el id del cuerpo, que va firmado, y no por X-Fital-Event-Id. Para recuperar eventos, pide GET /v1/events sin cursor y recorre hasta uno que ya procesaste. La cuenta de prueba ahora aplica las validaciones documentadas de moneda, pares de depósito, baja y estimación, y un beneficiario ajeno responde 404 not_found.
2026-11-05 · Mejora
El documento público declara Event.type y WebhookEndpoint.status como enumeraciones, Event.data con una forma por tipo, la sección webhooks, Retry-After en 409 y 503, 413 en cada operación con cuerpo, un ejemplo por código y el significado de cada valor. system.egress_ips.changing se emite con ip, change y effective_at. En la cuenta de prueba, POST /sandbox/v1/webhooks/trigger manda la forma real de cada tipo, GET /sandbox/v1/latam/countries responde available: false, y los escenarios de cobro y depósito dicen su final. Los destinos de webhook se gestionan sólo en el panel: v1 no publica operaciones para eso.
2026-11-05 · Mejora
Nuevo POST /v1/receiving-accounts: abre una cuenta para recibir en USD, EUR, BRL, GBP o COP, si tu empresa tiene esa moneda activada. Hay una por moneda: si ya existe responde 200 con esa misma cuenta y already_existed: true. MXN responde 422: tu CLABE ya aparece en GET /v1/receiving-accounts. Pide el permiso nuevo accounts:write, firma e Idempotency-Key. GET /v1/receiving-accounts suma sort_code, pix_key, br_code y bre_b_key, y ya devuelve el número de cuenta y el BIC de las monedas que antes llegaban vacíos.
2026-11-05 · Mejora
POST /v1/collections acepta method: "efectivo", bajo solicitud: cobros en tiendas de México, en MXN, de 20.00 a 10,000.00 por operación. La instrucción llega con type: "REFERENCE" y value, la referencia que quien paga da en la tienda. Se pide con amount, no con destination_amount, y sin expires_at vence a los 3 días. Se consulta en GET /v1/collections/{id} y avisa con collection.paid y collection.expired. En efectivo, paid dice que la tienda confirmó el pago; el abono a tu cuenta llega después. Está disponible bajo solicitud: pídelo a FITAL. Sale en GET /v1/collection-methods sólo cuando tu empresa lo tiene activado. El sandbox lo simula igual, con referencias ficticias.
2026-11-05 · Nuevo
GET /v1/latam/countries y GET /v1/latam/countries/{country}/entities dicen qué países, documentos, reglas de cuenta y bancos admite un alta latam. El alta acepta account_type, y Perú ya se puede registrar por API. GET /v1/collection-methods añade payer_fields, con lo que cada método pide de quien paga; el país de payer se deduce de la moneda. Son rutas y campos opcionales nuevos: las integraciones actuales siguen funcionando. Revisa la lista de migración.
2026-11-05 · Corrección
POST /v1/collections aplica payer_fields, en producción y en la cuenta de prueba. Sin un campo required, o con un valor fuera de options, responde 400 invalid_request y nombra el campo en details.fields, como payer.email, sin crear nada. Ese rechazo no cierra la clave, pero conserva su cuerpo: un cuerpo corregido necesita otra Idempotency-Key. Un cobro de prueba por SPEI pide firstName, lastName y email: sin payer antes daba 201 y ahora 400. GET /v1/payments/{id} trae failure_code también cuando el detalle ya no se puede leer: un pago failed da entonces payment_rejected. system.egress_ips.changing llega una vez a cada destino, también al que se activa hasta una hora antes del cambio; uno activado en esa última hora puede no recibirlo, y el aviso sigue en GET /v1/events. Un pago reenviado cuyo reenvío cae sigue en processing hasta que FITAL lo cierre. Revisa la lista de migración.
2026-11-05 · Corrección
Un alta latam con datos inválidos responde 422 invalid_beneficiary en vez de quedar en 202 processing. failure_code nunca es null en un pago failed, y todo evento payment.* lo trae. Un rechazo registrado responde retryable: false, también con in_review. El cuerpo tiene tope de 64 KB y más allá responde 413. Los webhooks llevan resource_id. GET /v1/collections/{id} devuelve instruction.type y expires_at. Repetir la clave de POST /v1/collections, POST /v1/deposit-addresses o POST /v1/beneficiaries tras un 202 entrega el resultado en cuanto existe. En GET /v1/movements una fila que cambia puede repetirse y nunca se omite otra. Una Idempotency-Key con otro cuerpo da 422 idempotency_key_reused también pasados 7 días. completed_at es null en un recibo que no terminó en completed. Las llaves de producción caducan a 180 días, con avisos a 30, 7 y 1 días. Revisa la lista de migración.
2026-11-05 · Mejora
POST /v1/deposit-addresses acepta todas las redes y tokens de Cobertura: USDC, USDT, EURC y PYUSD, ahora con solana, tron, avalanche, celo, tempo, linea y xdc. stellar no está disponible. En solana, tron, tempo, linea y xdc un depósito rechazado no regresa automáticamente: lo dicen la tabla y el warning de la dirección. EURC se acredita en EURC y suma a la fila EUR de GET /v1/balances. La respuesta trae siempre chain en minúsculas y currency en mayúsculas. La cuenta de prueba acepta los mismos pares.
2026-11-05 · Mejora
Nuevo GET /v1/wallets: lista las wallets de tu empresa con su red y su saldo disponible, en producción y en la cuenta de prueba. Es sólo consulta: las wallets no se crean ni se modifican por API. Pide el permiso nuevo wallets:read, que las llaves existentes no tienen: crea una llave con ese permiso. La suma por moneda es lo que da GET /v1/balances, salvo redondeo al centavo.
2026-11-04 · Mejora
GET /v1/payments/{id} añade freshness, con status (current o delayed) y as_of. Con delayed el estado es lo último que se sabe. Una cancelación confirmada responde canceled con delayed hasta que una lectura la confirme; un pago cancelado que vuelve a processing con current se reabrió de verdad. Es un campo opcional nuevo: las integraciones actuales siguen funcionando.
2026-11-04 · Nuevo
Primera versión pública del contrato v1: cuenta, beneficiarios, pagos, cobros, direcciones de depósito, depósitos, movimientos, recibos y eventos.
Errores comunes
- Vigilar sólo esta página. El RSS y el panel avisan lo mismo.