Primeros pasos
Integración / SDKs
Verificación de usuarios
Verificación de empresas
Monitorización de transacciones
Registro de cambiosvin o bank_account_number, así que las páginas de los servicios cuyas solicitudes incluyen esos campos solo muestran cURL.
Instalación
Configuración
Todos los SDK leen las mismas variables de entorno, así que un cliente creado sin opciones está listo para usarse. Los entornos edge no tienen variables de entorno de proceso: en ellos, pasa la clave de API al cliente de Node.js como opción.
Todo lo que puedes configurar mediante el entorno también puedes pasarlo al cliente, junto con la URL base, el tiempo de espera, los reintentos, los encabezados predeterminados y tu propio cliente HTTP. Crea un cliente por proceso y compártelo: mantiene un pool de conexiones y es seguro usarlo desde varios hilos o tareas.
Los métodos de
account (registro programático: registro, inicio de sesión, organizaciones y aplicaciones) invocan el endpoint https://apx.didit.me/auth/v2 y nunca envían tu clave de API. Inicia sesión con account.login y, después, pasa el token de acceso devuelto al cliente como su token de cuenta.
Qué hace cada SDK
- Recursos y métodos. Las llamadas siguen los recursos de la API:
client.<resource>.<method>(...), por ejemplosessions.create,sessions.retrieve_decisionotransactions.create, con la convención de mayúsculas y minúsculas de cada lenguaje. Los id de la ruta son argumentos posicionales; el cuerpo y la consulta son un único conjunto de campos con nombre. Python, Node.js, PHP y Ruby usan los nombres de campo de la propia API (workflow_id); Go, Java y .NET usan la convención de su lenguaje (WorkflowID,workflowId,WorkflowId). - Listas. Los métodos de listado recorren todos los resultados por ti (con
limityoffsetinternamente) y además exponen cada página concount,next,previousyresults. En Ruby,auto_paging_eachrecorre todas las páginas, y lostotal_count,next_urlyprevious_urlde una página son loscount,nextypreviousde la API. - Archivos. Las subidas (imágenes de documentos, selfies, prueba de domicilio, importaciones) aceptan una ruta, bytes o un stream. Las descargas (PDF de sesiones, informes) devuelven bytes o un stream, nunca JSON analizado.
- Compatibilidad futura. Un campo de respuesta o un valor de enum que la versión del SDK aún no conoce se conserva y se puede leer, nunca produce un error, así que una incorporación a la API no rompe una integración ya desplegada.
- Webhooks.
webhooks.verifycomprueba los encabezadosX-Signature-V2yX-Signaturey la marca de tiempo de una entrega con tu secreto de webhook, y devuelve un evento tipado. Acepta una lista de secretos mientras rotas uno. Consulta Webhooks para conocer el esquema de firma. - Authentication. Un helper
Authenticationverifica los tokens de acceso y de ID que firma tu emisor de Authentication, e invoca sus endpoints de token, de sesión y de step-up. Nunca usa tu clave de API.
Errores, reintentos y tiempos de espera
Todos los errores derivan de
DiditError. En Go, todos los errores implementan la interfaz didit.Error y son de tipo puntero, como *didit.NotFoundError. Java, PHP y .NET los nombran con su sufijo habitual Exception y escriben API como Api: DiditException, ApiStatusException, NotFoundException.
Los SDK reintentan una solicitud fallida hasta 2 veces, con backoff exponencial a partir de 0,5 segundos (jitter completo, como máximo 8 segundos) y respetando Retry-After. GET, HEAD, PUT y DELETE se reintentan ante errores de conexión, tiempos de espera agotados, 408, 429 y 5xx. POST y PATCH solo se reintentan ante un 429 o cuando la conexión falló antes de enviar la solicitud, de modo que un reintento nunca crea una segunda sesión o transacción. El tiempo de espera predeterminado es de 60 segundos. Cada respuesta expone además el estado HTTP sin procesar, los encabezados y el ID de la solicitud. Consulta Límite de solicitudes para conocer los límites que hay detrás del 429.
Versionado y soporte
- Los SDK siguen el versionado semántico. Cuando un endpoint se elimina de la API o se renombra su método, el método anterior se mantiene al menos una versión menor más, marcado como obsoleto, para que tu código siga compilando mientras migras al nuevo.
- Se generan a partir del contrato publicado de la API (
openapi-25.jsonyopenapi-auth.json) y lo comprueban cada día, así que un nuevo endpoint o campo llega en una versión ordinaria de los siete SDK. - Cada SDK es compatible con el runtime mínimo de la tabla y con todas las versiones posteriores. Sus pruebas se ejecutan en el mínimo y en cada versión posterior, o en cada versión de soporte a largo plazo en el caso de Node.js y Java.
- El
CHANGELOG.mdde cada repositorio enumera los cambios de cada versión. - Informa de un problema de seguridad de forma privada mediante los avisos de seguridad del repositorio del SDK o escribiendo a support@didit.me.