Saltar al contenido principal

6 publicaciones etiquetados con "cambios"

Ver Todas las Etiquetas

API 1.21.0 - Convenio vigente en el saldo y tarifas por tipo de emisión

· 3 min de lectura

Aquí resumimos lo que cambió para los integradores desde la entrada 1.20.0, que introdujo el tipo de emisión por solicitud. Esta versión completa ese cambio en las tarifas y añade el convenio vigente al saldo. Las rutas siguen bajo el prefijo /api/v1.

Cambios que requieren acción
  • Cada tipo de emisión se cotiza con sus propias tarifas: GET /pricing y POST /orders usan siempre la lista de precios del tipo pedido en issuance_flow (sin él, la del tipo por defecto de tu empresa). En la 1.20.0 los dos tipos se cotizaban con las mismas tarifas. Si guardabas precios en tu sistema, vuelve a consultarlos por tipo.
  • Lista vacía o 422 según tu plan: si tu tipo de usuario no tiene tarifas para un tipo de emisión, GET /pricing?issuance_flow=<TIPO> devuelve [] (no es un error: no ofrezcas esa compra), y la cotización (quantity + vigencia) y POST /orders responden 422 con error_code = PRICING_TIER_NOT_FOUND.

API 1.21.1 - Webhooks y correos del resultado de los pagos

· 3 min de lectura

Aquí resumimos lo que cambió para los integradores desde la entrada 1.21.0. Esta versión corrige el aviso del resultado de los pagos: los webhooks payment.approved y payment.failed empiezan a entregarse y el usuario que creó la orden recibe un correo con el resultado. Las rutas siguen bajo el prefijo /api/v1.

Sin cambios obligatorios

Ninguna operación cambia. Si ya consultas GET /orders/{uuid} para conocer el resultado de un pago, tu integración sigue funcionando igual. Para dejar de consultar una y otra vez, suscribe tu webhook a payment.approved y payment.failed.

API 1.20.0 - Tipo de emisión por solicitud (biométrica o documental)

· 8 min de lectura

Aquí resumimos lo que cambió para los integradores desde la entrada 1.19.5. La novedad principal es el tipo de emisión por solicitud (issuance_flow): biométrica o documental, con precios, compras y cupos separados por tipo. Incluye también las versiones 1.19.6 a 1.19.10. Las rutas siguen bajo el prefijo /api/v1.

Todo es aditivo: si tu integración no cambia nada, sigue creando solicitudes, comprando y consultando el saldo como hasta ahora (ver «Compatibilidad»). Revisa sobre todo los puntos de abajo.

Cambios que requieren acción
  • issuance_provider puede valer dual y ya no llega null: en el login, en GET /company y en GET /quota/status vale viafirma, mail o dual. dual significa que tu empresa puede elegir el tipo de emisión en cada solicitud. Si en el futuro llega un valor distinto de viafirma, mail y dual, no lo trates como mail: no crees solicitudes y contacta a soporte.
  • Decide por la solicitud, no por la empresa: cada solicitud trae issuance_flow (BIOMETRIC o DOCUMENTARY). Úsalo para saber si la emisión arranca sola, si hay verificación de identidad o si debes llamar a /issue. Una empresa dual tiene solicitudes de los dos tipos.
  • El cupo es por tipo de emisión: una solicitud solo consume certificados de su mismo tipo. Sin cupo, el 402 trae ahora error_code = QUOTA_EXHAUSTED, un message que nombra el tipo (No tiene certificados disponibles de tipo Documental (sin biometría) para vigencia de 1 año(s)…), issuance_flow, vigencia y available_in_other_flows. Si comparabas el texto del mensaje, guíate por error_code.
  • postpaid de GET /quota/status ahora suma todos los cupos pospago vigentes del tipo, y expires_at es el vencimiento más próximo. Antes mostraba solo el cupo pospago más reciente, así que el número puede subir.
  • POST /orders sin rango de precios responde 422 con error_code = PRICING_TIER_NOT_FOUND. Antes respondía 500.
  • Empresas viafirma cuando la emisión biométrica no está disponible: POST /certificate-request responde 400 con error_code = ISSUANCE_FLOW_UNAVAILABLE y la solicitud no se crea ni consume cupo. Antes la solicitud se creaba y fallaba después, al emitir.

API 1.19.5 - 404 en recursos inexistentes y errores sin detalles internos

· 7 min de lectura

Aquí resumimos lo que cambió para los integradores desde la entrada 1.19.1. Incluye las versiones 1.19.2 y 1.19.3, con cambios en las respuestas de error, la emisión con Viafirma y los pagos de órdenes, y las versiones 1.19.4 y 1.19.5, que revisan la referencia de la API sin cambiar su funcionamiento. Las rutas siguen bajo el prefijo /api/v1.

Cambios que requieren acción
  • Un recurso inexistente responde 404 en lugar de 500: en las operaciones que se listan más abajo, en «Recursos inexistentes», la API responde 404 con {"success":false,"message":"Recurso no encontrado."}. Antes respondía 500 y el mensaje incluía detalles internos. Si tu integración trataba ese 500 como "aún no existe" o como error del servidor, trata ahora el 404.
  • Corrección a la entrada 1.19.1: allí indicamos que GET /certificate-request/{id}/kyc-link responde 500 mientras el trámite de Viafirma aún no existe (justo después de crear la solicitud). Desde la 1.19.2 responde 404 con message = Recurso no encontrado.: si la emisión con Viafirma está por iniciarse, reintenta más tarde.
  • POST /certificate-request/{id}/issue puede responder 503: lo hace cuando no se puede proteger la llave del certificado en el servidor (ver «Emisión con Viafirma» más abajo). Antes ese fallo respondía 422. Es un error temporal: reintenta más tarde.

API 1.18.1 - Cambios desde la documentación de julio de 2026

· 8 min de lectura

Desde esta entrada, la referencia de la API sigue la versión del backend. Aquí resumimos lo que cambió para los integradores desde la documentación publicada en julio de 2026. Las rutas siguen bajo el prefijo /api/v1.

Cambios que requieren acción
  • POST /certificate-request se envía en JSON (application/json), ya no en multipart/form-data. Los adjuntos van en attachments[], con el contenido del archivo en base64 y, de forma opcional, name, type y size.
  • Nuevos campos obligatorios al crear una solicitud: country_id, accept_terms (debe venir aceptado, por ejemplo true) y terms_version_id, que es el id que devuelve GET /terms/current y debe corresponder a la versión vigente de los Términos y Condiciones. Si falta alguno, o la versión ya no es la vigente, la API responde 400 con el detalle por campo en errors.
  • legal_representative solo es obligatorio si no envías legal_rep_first_name y legal_rep_last_name. Si tu empresa emite con Viafirma, debes enviar los nombres y apellidos por separado y legal_rep_email.
  • POST /certificate-request/{id}/files también recibe JSON con attachments[] en Base64, en lugar del campo file en multipart/form-data.
  • La revocación usa el UUID público de la solicitud: POST /certificate-request/{uuid}/revoke reemplaza a POST /certificate-request/{id}/revoke. Con un ID numérico, o con un UUID que no pertenece a tu empresa, la API responde 404.
  • Solo se entregan certificados vigentes: GET /certificate-request/{uuid}/issuance/download, su variante /download/base64 y la descarga de archivos de tipo CERTIFICATE responden 409, con el estado actual en status, si la solicitud no está en PROCESSED (revocada, vencida, cancelada, rechazada o aún en trámite).

API 1.19.1 - Cambio de correo con contraseña y referencia verificada

· 7 min de lectura

Aquí resumimos lo que cambió para los integradores desde la entrada 1.18.1. Incluye la versión 1.19.0, con cambios de comportamiento en la cuenta, la empresa, los mensajes de error y la emisión con Viafirma, y la 1.19.1, que revisa la referencia completa de la API sin cambiar su funcionamiento. Las rutas siguen bajo el prefijo /api/v1.

Cambios que requieren acción
  • Cambiar tu propio correo con PUT /profile/{id} exige tu contraseña actual: envíala en records.current_password. Si falta o no es correcta, la API responde 422 con el detalle en errors.current_password y no guarda nada.
  • El correo nuevo debe verificarse antes del próximo inicio de sesión: tu token actual sigue funcionando, pero POST /auth/login responde 400 hasta que se abra el enlace de verificación que se envía al correo nuevo. La respuesta del cambio lo indica con email_verification_required = true.
  • El correo de la cuenta y el de la empresa ya no se pueden vaciar: en PUT /profile/{id} y PUT /company/{id}, un records.email vacío, solo con espacios o null responde 422 (El correo electrónico es obligatorio: no se puede dejar vacío.). Antes se guardaba vacío. Si no quieres cambiar el correo, omite el campo email.