Uso de CertivantLive ID y desarrolloDesarrollador: claves de API y API REST

Desarrollador: claves de API y API REST

Emita y gestione claves de API, configure los ámbitos y use la API REST de Certivant para crear solicitudes de verificación y sincronizar el estado KYC de forma programática desde sus propios sistemas.

Who can do this:Org ownerOrg admin— Los miembros necesitan el permiso api.access para ver. Emitir claves requiere ser administrador.

Qué hace

La API REST de Certivant permite a sus propios sistemas crear solicitudes de verificación, subir documentos y consultar el estado sin pasar por el panel. Dos casos de uso principales:

  1. Integrar la verificación en su propio flujo de alta. Su formulario de registro envía los datos a su backend, su backend llama a Certivant y el solicitante recibe un enlace al flujo alojado de Certivant.
  2. Sincronizar el estado de la verificación con su almacén de datos o su CRM. Combínela con los webhooks para que sus sistemas se actualicen con cada cambio de estado.

La autenticación de la API se realiza mediante claves de API que emite desde el panel. La documentación completa de los endpoints está en /app/{su-org}/kyc/developer; esta página cubre la gestión de claves y la visión general conceptual.

Dónde está

KYC → Desarrollador en la barra lateral izquierda. (Antes, las claves de API estaban en los ajustes de KYC/B; ahora tienen su propio espacio en Desarrollador.)

El portal para desarrolladores es un único centro con un menú a la izquierda:

  • Resumen e inicio rápido: su URL base, la autenticación y una petición lista para copiar en 8 lenguajes (cURL, JavaScript, TypeScript, Python, PHP, Go, Java, C#). Los fragmentos vienen rellenados con su host real y un marcador para su clave.
  • Claves de API: lista, crea y revoca sus claves.
  • Referencia de endpoints: cada endpoint de la integración (/v1) con su método, ruta, ámbitos y parámetros, además de un enlace al Playground interactivo de la API.
  • Manejadores de webhooks: manejadores listos para usar que verifican la firma, en 6 lenguajes (consulte también Webhooks).
  • Límite de peticiones: el límite efectivo por minuto de su organización, en modo de solo lectura.
  • Preguntas frecuentes: las preguntas que más hacen los integradores.

Emitir una clave de API

Haga clic en Nueva clave

La tarjeta Claves de API de la parte superior de la página Desarrollador enumera sus claves con su entorno, sus permisos, la fecha de creación y el último uso. Cada fila tiene botones para editar, rotar y revocar la clave.

La tarjeta Claves de API de la página Desarrollador: cada clave muestra sus distintivos de entorno y permisos, el prefijo de la clave, cuándo se creó y se usó por última vez, y los botones de editar, rotar y revocar.

Se abre un diálogo.

El diálogo Crear clave API: una etiqueta, el entorno Producción o Prueba, los permisos Lectura, Escritura, Envío y Gestión, y los permisos por recurso.

Póngale un nombre

Elija una etiqueta que indique dónde se usa la clave: «Backend de producción (Heroku)», «Pipeline de CI», «Desarrollo local: portátil de Alice». El nombre aparece en el registro de auditoría junto a cada acción de la API.

Elija los ámbitos

Los permisos se definen por clave. Hay dos formas de concederlos, y puede combinarlas:

ÁmbitoQué permite
kyc:readLeer cualquier cosa: solicitudes, documentos, formularios, analíticas.
kyc:writeCrear y modificar: solicitudes, subidas de documentos, envíos de formularios, verificaciones en vivo.
kyc:submitEnviar una solicitud al procesamiento automático.
kyc:manageAcciones privilegiadas: anular decisiones, eliminar documentos, borrar o exportar los datos de un solicitante.

O bien elija permisos más restringidos, por recurso (Lectura, Escritura, Envío y Gestión para cada recurso):

RecursoÁmbitosAbarca
Verificacionesverifications:read · write · submit · manageSolicitudes de verificación, KYB, EDD, señales de fraude
Formulariosforms:read · write · manageLista de formularios, envío de formularios, seguimiento de entregas
Documentosdocuments:read · write · manageDocumentos de la solicitud
Verificación Live IDlive_id:read · writeProgramación y seguimiento de las llamadas de verificación en vivo
Webhookswebhooks:read · managePuntos de conexión de webhooks (deben concederse de forma explícita)
Analíticasanalytics:readAnalíticas y resumen de triaje
Privacidad y supresiónprivacy:manageSolicitudes de eliminación, supresión y exportación por solicitante

Gestión en un recurso incluye todas las demás acciones sobre ese recurso. Un ámbito por recurso nunca llega más allá de su recurso: una clave con solo forms:read no puede leer solicitudes de verificación.

Elija los mínimos ámbitos que la clave necesita de verdad. Una clave para «enviar un formulario desde nuestro flujo de registro» solo necesita forms:write.

(Opcional) Restrinja la clave

  • Formularios: limite la clave a formularios concretos. Entonces solo puede listar, enviar y crear verificaciones a través de esos formularios, y solo ve las verificaciones creadas a través de ellos (lista, detalle, documentos, resumen y analíticas). Cualquier otra cosa se rechaza con 403 form_not_allowed. Una clave restringida a formularios no puede crear una verificación sin indicar uno de sus formularios (formId), y no puede usar los endpoints de supresión de solicitantes, de solicitudes de eliminación, de reutilización y de verificación en vivo. Las verificaciones que ya existían antes de aplicarse esta restricción pasan a ser visibles para una clave restringida cuando Certivant ejecuta su rellenado único.
  • Flujos de trabajo: limite la clave a flujos de trabajo de automatización concretos. Para cada verificación que cree la clave, solo pueden ejecutarse esos flujos (sea quien sea el que los dispare después: el solicitante, una decisión o un revisor); los demás flujos se omiten para esa verificación. Las verificaciones creadas desde el panel, por solicitantes en un formulario público o por otras claves no se ven afectadas. Ninguna llamada a la API falla por esta restricción.

Deje todo sin marcar para no aplicar restricciones.

  • Direcciones IP: enumere las direcciones IPv4/IPv6 o los rangos CIDR desde los que puede usarse la clave (una por línea, por ejemplo 203.0.113.7, 198.51.100.0/24, 2001:db8::/32). Las peticiones desde cualquier otra dirección se rechazan con 403 ip_not_allowed.

La mitad inferior del diálogo Crear clave API: la lista Limitar a formularios, el cuadro de Direcciones IP permitidas, la fecha de caducidad opcional y el botón Crear clave API.

Puede cambiar más adelante los ámbitos, las restricciones y la caducidad con Editar (el icono de lápiz): el secreto y el entorno no pueden modificarse.

El diálogo Editar clave API: los mismos permisos y restricciones que al crear la clave; el entorno aparece en gris porque no puede cambiarse.

(Opcional) Caducidad

Establezca una fecha en la que la clave caduque automáticamente. Recomendado para integraciones de corta duración (tokens de CI, demostraciones). Las claves de producción suelen no tener caducidad; en su lugar, rótelas según un calendario. Una clave caducada devuelve 401 api_key_expired.

Elija el entorno

Las claves de Producción empiezan por ck_live_, y las de Prueba por ck_test_ (consulte Producción frente a pruebas más abajo).

Cree la clave

La clave se muestra una sola vez en una ventana modal. Cópiela ahora: no podrá recuperarla después. El panel muestra solo el prefijo (por ejemplo, ck_live_a3f1) para identificar las claves sin exponerlas.

Usar la clave

Envíela en la cabecera Authorization:

Authorization: Bearer ck_live_a3f...

Las claves creadas antes del formato ck_live_ / ck_test_ (que empiezan por kyk_) siguen funcionando sin cambios.

La forma más rápida de tener una integración funcionando:

Cree una solicitud

curl https://api.certivant.com/api/v1/kyc/requests \
  -H "Authorization: Bearer $CV_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "type": "INDIVIDUAL",
    "applicant": {
      "fullName": "Jane Doe",
      "email": "jane@example.com"
    }
  }'

Devuelve el id de la nueva solicitud y una URL de un solo uso donde el solicitante sube sus documentos.

Envíe al solicitante a la URL

Puede enviarle el enlace por correo electrónico usted mismo, integrarlo en su propio flujo de alta o pedirnos que se lo enviemos desde el flujo «Enviar invitación» del panel.

Reciba el resultado mediante webhook o por consulta

  • Webhook (recomendado): registre un punto de conexión que gestione kyc.request.approved / rejected / escalated. Consulte Webhooks.
  • Consulta periódica: GET /api/v1/kyc/requests/{id} devuelve el estado actual. Intervalo recomendado: ≥ 30 s.

Atribución a socios y subinquilinos

Si realiza verificaciones en nombre de muchos clientes finales desde una sola organización (el patrón clásico de socio o revendedor, por ejemplo, una plataforma de firma electrónica que verifica a los firmantes de cientos de empresas), no necesita una organización por cliente. Etiquete cada solicitud con dos campos opcionales al crearla mediante la API:

  • subTenantName: el nombre visible del cliente final (por ejemplo, «Acme Corp»).
  • subTenantExternalId: su propio identificador interno de ese cliente (por ejemplo, cust_8842).

Una vez etiquetadas, puede:

  • Filtrar el endpoint de listado por subTenantExternalId (GET /api/v1/kyc/requests?subTenantExternalId=cust_8842).
  • Enrutar los webhooks: ambos campos se repiten en cada sobre de evento, de modo que su manejador sabe a qué cliente pertenece un resultado sin necesidad de una consulta adicional.
  • Filtrar los paneles: Uso de KYC/B, Registro de auditoría, Monitorización, Informes y Analíticas incorporan un filtro de Subinquilino en cuanto alguna solicitud lleva las etiquetas, y las listas de KYC/KYB pueden mostrar las columnas Subinquilino e ID externo (ocultas por defecto; actívelas desde el menú de columnas).

Consulte la referencia de la API para ver la forma exacta de la petición: Solicitudes KYC → Crear una solicitud.

Límites de peticiones

Su límite de peticiones por minuto de la API lo define su plan (valores típicos: 60/min en Launch, 300/min en Pro/Scale, 600/min en Enterprise). El límite exacto de su organización aparece en modo de solo lectura en la página Desarrollador, y cada respuesta de la API lo incluye en la cabecera X-RateLimit-Limit. Cada clave se mide de forma independiente dentro de ese límite.

Si lo supera, las peticiones devuelven HTTP 429 Too Many Requests con X-RateLimit-Reset (segundos hasta que se reinicia la ventana). Espere y reintente.

¿Necesita un límite mayor? Su superadministrador lo establece: puede subir su límite por cliente hasta el máximo de su plan desde Administración → Clientes → (su organización) → Editar organización (un límite mayor implica pasar a un plan superior). El límite lo controla el operador: los inquilinos pueden verlo, pero no modificarlo. Consulte la referencia para desarrolladores con el funcionamiento completo: Límites de peticiones.

Buenas prácticas de seguridad

  • Guarde las claves en variables de entorno o en un gestor de secretos. Nunca las suba a git ni las comparta en un chat. Las claves subidas a repositorios públicos son escaneadas y robadas en cuestión de minutos.
  • Una clave por entorno. No comparta una clave ck_live_... entre preproducción y producción: rotar una no debe afectar a la otra.
  • Use claves con ámbitos. Una clave de solo lectura para monitorización y una clave de escritura para el servicio de alta es más segura que una única clave omnipotente en todas partes.
  • Restrinja las claves a sus servidores. Añada la lista de IP permitidas para las claves que se usan solo desde direcciones fijas.
  • Rote las claves trimestralmente. Use Rotar (más abajo): la clave antigua sigue funcionando durante el solapamiento que elija, de modo que puede desplegar la nueva sin interrupción. El registro de auditoría registra el cambio.
  • Vigile el uso no autorizado. La lista de claves muestra cuándo y desde qué dirección se usó por última vez cada clave, y el registro de auditoría registra la creación, las ediciones, las rotaciones y las revocaciones. Investigue cualquier dirección que no reconozca.

Rotar una clave

El diálogo Rotar clave API: cuántas horas sigue funcionando la clave antigua (de 0 a 168) y el botón Rotar clave.

Desarrollador → Claves de API → Rotar crea un reemplazo con la misma etiqueta, los mismos permisos, restricciones, lista de IP permitidas y caducidad, y muestra la nueva clave una sola vez.

  • Solapamiento (de 0 a 168 horas, por defecto 24). La clave antigua sigue funcionando durante ese tiempo y después devuelve 401 api_key_rotated. Establezca 0 para revocar la clave antigua de inmediato.
  • La lista marca la clave antigua como «Rotada: la clave antigua funciona hasta …» y la nueva como «Reemplaza una clave rotada». Una clave que ya ha sido rotada no puede volver a rotarse: rote su reemplazo.
  • También puede editar o revocar la clave antigua durante el solapamiento si necesita cortarla antes.

Revocar una clave

Cuando una clave está comprometida, filtrada o ya no se necesita:

  • Desarrollador → Claves de API → menú de tres puntos → Revocar.
  • Surte efecto de inmediato. Cualquier petición en curso que use la clave recibirá un 401 en la siguiente llamada.
  • No puede deshacerse: no hay botón de «anular la revocación». Emita una clave nueva si se arrepiente.

La revocación queda registrada en el registro de auditoría, junto con el usuario que la realizó.

Producción frente a pruebas

Cada clave es de una de estas dos clases:

  • Prueba (ck_test_...): pensada para desarrollo y CI.
  • Producción (ck_live_...): pensada para producción.

El entorno etiqueta el uso: cada respuesta incluye X-Certivant-Environment: test o live, y el panel muestra el distintivo junto a la clave, de modo que puede distinguir el tráfico de prueba del de producción en sus registros.

Las claves de prueba no aíslan los datos. Leen y escriben las mismas verificaciones que sus claves de producción. El único entorno de pruebas es el que tiene cada organización nueva al empezar: hasta que Certivant verifique su organización, las funciones de verificación en vivo están bloqueadas para todas sus claves. Use una organización distinta si necesita datos de prueba totalmente separados.

Solución de problemas

401 Unauthorized

El campo error.reason del cuerpo de la respuesta indica el motivo:

error.reasonSignificado
missing_api_keyNo hay cabecera Authorization: Bearer ….
invalid_api_keyLa clave no existe (error tipográfico, truncada, organización equivocada).
api_key_revokedLa clave fue revocada.
api_key_expiredHa pasado la fecha de caducidad de la clave.
api_key_rotatedLa clave fue rotada y su periodo de solapamiento terminó. Use el reemplazo.

403 Forbidden

error.reason:

error.reasonSignificado
insufficient_scopeLa clave no tiene el ámbito necesario para el endpoint (el mensaje indica los ámbitos admitidos). Edite la clave o emita una nueva.
ip_not_allowedLa petición procede de una dirección que no está en la lista de IP permitidas de la clave.
form_not_allowedLa clave está restringida a otros formularios: el formulario, o la verificación que pidió, no se creó a través de ninguno de ellos.

429 Too Many Requests

Tiene un límite de peticiones. Consulte la cabecera Retry-After (segundos) y espere en consecuencia. Si necesita un volumen sostenido, solicite un límite mayor.

«He perdido el valor de la clave»

Las claves se muestran una sola vez. No hay forma de recuperarlas. Revoque la clave antigua y emita una nueva: su equipo tendrá que actualizar el nuevo valor allí donde estaba desplegado el antiguo.