Saltar al contenido principal

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.

Cambios de comportamiento​

Tarifas siempre del tipo de emisión solicitado​

  • GET /pricing: los rangos que devuelve son los del tipo pedido y cada uno trae ese mismo issuance_flow. Lo mismo aplica a la cotización, que además trae tier_name.
  • POST /orders: la orden se cotiza con la lista del tipo de la compra, y la respuesta trae issuance_flow y tier (el código del rango aplicado).
  • Renovación: sigue cotizándose con las tarifas de la emisión biométrica, como antes.
  • El último rango de una lista puede no tener tope (max = null): muéstralo como «N+ certificados».

Detalle en Precios y Órdenes.

Convenio vigente en GET /quota/status​

  • Nuevo campo has_agreement (booleano, nunca null) en el primer nivel de GET /quota/status: true si tu empresa tiene convenio (pospago) y false si es prepago. También llega en el bloque quota de GET /certificate-request/stats/{companyId}.
  • Es el valor vigente y tiene precedencia sobre company.has_agreement del login, que es una foto del momento del inicio de sesión. Si tu integración decide con ese valor (por ejemplo, ofrecer o no la compra de certificados), léelo de GET /quota/status.
  • El convenio no cambia cómo se consumen los cupos: los certificados pospago y prepago que tengas se siguen usando igual.
  • GET /company sigue devolviendo has_agreement como entero (0/1). PUT /company/{id} no lo modifica: si lo envías en records, se ignora.

Detalle en Cupos y Empresa.

Documentación​

  • La referencia de la API documenta las tarifas por tipo de emisión, el 422 PRICING_TIER_NOT_FOUND y el campo has_agreement de GET /quota/status.
  • Las guías se actualizaron con el tipo de emisión por solicitud, el saldo y las compras por tipo, y las estadísticas con filtro por tipo.

¿Vas a actualizar una integración existente? Revisa la guía paso a paso, los casos de uso y la solución de problemas.