Precios

Tarifas por volumen en COP (vigencia 1 o 2 años) según el tipo de usuario autenticado; requiere Bearer Token. Los precios incluyen IVA (19% por defecto). Hay una lista por tipo de emisión (?issuance_flow= BIOMETRIC / DOCUMENTARY; sin él, el de la empresa); siempre se responde y se cotiza con la lista del tipo pedido.

📄️Consultar tarifas o calcular el precio de certificados

Requiere autenticación (cualquier usuario). Las tarifas dependen del tipo del usuario autenticado (`type_id`): 1 → `INCLUDED`, 2 → `SOFTWARE_HOUSE`, 3 → `SERVER_RANGE_n`, 4 → `PARTNER_RANGE_n`. Precios en COP con IVA incluido. Dos modos: (1) sin `quantity` y `vigencia` (o con solo uno de ellos, que se ignora) retorna en `dataRecords.data` el arreglo de rangos activos del tipo de usuario, ordenados; (2) con ambos parámetros retorna en `dataRecords.data` un objeto con el precio calculado. En el modo (2), para los tipos 3 y 4 el rango se elige por `effective_quantity` = certificados vigentes de la empresa + `quantity`. Se cuentan las solicitudes de la empresa creadas el año actual o el anterior, en estado `PROCESSED` o `PROCESSING`, y que sigan vigentes según su vigencia: con `life` = 1, sin fecha de vencimiento o con vencimiento posterior al momento de la consulta; con `life` = 2, sin fecha de vencimiento o con vencimiento posterior a un año desde el momento de la consulta (un certificado de 2 años que ya está en su segundo año no se cuenta). Para los demás tipos `effective_quantity` = `quantity`. El volumen suma las solicitudes de los dos tipos de emisión. Siempre se factura por `quantity`. **Tipo de emisión (`issuance_flow`):** cada tipo de usuario tiene una lista de precios por tipo de emisión (BIOMETRIC, la de los rangos anteriores, y DOCUMENTARY, rangos `DOC_<TIPO>_RANGE_n`). Sin `issuance_flow` se usa el de la empresa (`viafirma` → BIOMETRIC; `mail` y `dual` → DOCUMENTARY); con él, debe estar permitido para la empresa. Siempre se responde con la lista del tipo de emisión solicitado (o el de la empresa si no se envía): los rangos llegan con ese mismo `issuance_flow`. Un tipo de usuario sin tarifas para el tipo de emisión pedido recibe un arreglo vacío en el modo (1) y 422 `PRICING_TIER_NOT_FOUND` en el modo (2).