Autenticació
Tots els endpoints de l’API de gestió utilitzen la clau d’API de la teva aplicació. No cal incloure UUID d’organització ni d’aplicació a les URL, perquè l’aplicació s’identifica a partir de la teva clau.Fluxos de treball
Els fluxos de treball defineixen els passos de verificació que segueixen els teus usuaris (escaneig del document d’identitat, prova de vida, coincidència facial, cribratge AML, etc.). Cada flux de treball és una configuració reutilitzable que associes a les sessions.GET
Llista tots els fluxos de treball de la teva aplicació. Retorna les funcionalitats de cada flux, els llindars i si és el flux per defecte.
POST
Crea un flux de treball nou. Defineix quines funcionalitats de verificació s’activen, estableix els llindars, configura els tipus de document acceptats i més.
GET
Obté els detalls complets d’un flux de treball concret, incloses totes les configuracions de funcionalitats i els llindars.
PATCH
Actualitza la configuració d’un flux de treball. Pots modificar qualsevol configuració de funcionalitat, llindar o document acceptat.
DELETE
Elimina un flux de treball. Les sessions que ja fan servir aquest flux no es veuen afectades.
Exemple ràpid: crear un flux de treball
Elworkflow_type determina el conjunt de funcionalitats base. Després, les funcionalitats individuals s’activen o desactiven amb les marques is_*_enabled.
workflow_type: kyc, kyb, adaptive_age_verification, biometric_authentication, address_verification, questionnaire_verification, email_verification, phone_verification.
En els fluxos kyc, la verificació d’identitat s’inclou automàticament, de manera que no necessites una marca separada per a aquesta funcionalitat. Utilitza les marques is_*_enabled per afegir o eliminar funcionalitats opcionals com la coincidència facial, la prova de vida, l’AML, NFC, el telèfon, el correu electrònic, el comprovant de domicili, l’anàlisi de dispositiu i IP, i més.
Després, utilitza el flux de treball en crear sessions:
Qüestionaris
Formularis personalitzats que pots afegir als fluxos de verificació per recollir informació addicional dels usuaris.GET
Llista tots els qüestionaris.
POST
Crea un qüestionari nou amb preguntes personalitzades, lògica de ramificació i traduccions.
GET
Obté els detalls del qüestionari, incloses totes les preguntes i l’estructura del formulari.
PATCH
Actualitza un qüestionari.
DELETE
Elimina un qüestionari.
Usuaris
Gestiona les persones verificades (usuaris) de la teva aplicació. Cada usuari s’identifica amb una cadenavendor_data que proporciones en crear les sessions.
GET
Llista tots els usuaris de la teva aplicació, inclòs el seu estat de verificació i l’historial de sessions.
GET
Obté els detalls d’un usuari a partir del teu identificador vendor_data.
PATCH
Actualitza les metadades de l’usuari.
POST
Elimina usuaris per lots. Cos:
{"vendor_data_list": ["user-1", "user-2"]} o {"delete_all": true}. També purga totes les plantilles biomètriques conservades per a aquests usuaris.Plantilles biomètriques
Plantilles biomètriques facials sense imatges que una aplicació que ha donat el seu consentiment conserva després d’eliminar sessions. Consulta Plantilles biomètriques.GET
Llista paginada amb filtres (
vendor_data, vendor_user_uuid, status, source_type, retained_from, retained_to, ordering).GET
Recompte amb els mateixos filtres.
GET
Una plantilla: l’usuari propietari, la referència d’origen, la caducitat, la instrucció i l’estat.
DELETE
Purga una plantilla. Retorna
{"uuid": "...", "outcome": "purged" | "already_purged"}.POST
Purga per lots. Cos:
{"template_uuids": [...]} o {"delete_all": true}, més filtres opcionals.Operacions amb sessions
POST
Elimina sessions per lots. Requereix
delete:sessions. Cos: {"session_numbers": ["1", "2", "3"]} o {"delete_all": true} (acota delete_all amb els filtres de la llista de sessions amb el prefix filter_, com filter_status), més les opcions retain_face_embeddings, face_retention_days, face_retention_deadline, deletion_instruction i instruction_id. Fins a 20 sessions coincidents retornen 200 amb un face_retention_outcome per sessió; si n’hi ha més, retornen 202 amb una tasca d’eliminació.GET
Progrés i recomptes dels resultats d’una eliminació de sessions per lots que ha retornat
202.GET
Llista les revisions i el registre d’activitat d’una sessió.
POST
Afegeix una nota de revisió o un canvi d’estat a una sessió.
Facturació
GET
Obtén el saldo de crèdit actual i la configuració de recàrrega automàtica.
POST
Crea una sessió de pagament de Stripe per recarregar crèdits. Cada recàrrega va de $50 a $20,000 i s’afegeix pel valor nominal.
Llistes (llistes de bloqueig, llistes d’autorització i personalitzades)
Gestiona llistes tipificades per a bloqueig, autorització i condicions personalitzades de flux de treball. Consulta la documentació completa de l’API de llistes.GET
Llista totes les llistes de l’aplicació (de bloqueig, d’autorització i personalitzades).
POST
Afegeix una entrada a una llista. Admet
reference_session_id per extreure automàticament dades d’una sessió, i reference_object_uuid per a la traçabilitat cap a transaccions, usuaris o empreses.DELETE
Elimina una entrada d’una llista.
POST
Puja una imatge facial a una llista de bloqueig facial (base64).
Configuració del webhook
GET
Obtén la configuració actual del webhook, inclosa la URL, la versió, la clau secreta per verificar les signatures dels webhooks, i la política de conservació de dades i de plantilles biomètriques de l’aplicació.
La resposta també inclou
allowed_domains, descrit a continuació, a PATCH /v3/webhook/.PATCH
Actualitza la URL del webhook, la versió o renova la clau secreta. Defineix
rotate_secret_key: true per generar un nou secret de webhook (l’anterior queda invalidat immediatament). També defineix la política de conservació de l’aplicació: data_retention_months i face_retention_policy (delete_with_session per defecte, o retain_until_user_deleted), juntament amb face_retention_days obligatori i finit (1-3650) quan la conservació està habilitada. Consulta Conservació de plantilles biomètriques. També registra allowed_return_hosts: fins a 20 noms d’amfitrió simples (per exemple app.example.com, sense esquema, port, camí ni comodí) als quals una verificació de Digital ID wallet API pot retornar la persona per HTTPS. Una llista nova substitueix la registrada, i el domini de marca blanca de la teva aplicació sempre està permès.També defineix allowed_domains: fins a 50 orígens web (per exemple https://app.example.com) on es pot incrustar el flux de verificació allotjat i als quals pot retornar l’usuari amb un callback de sessió.
Cada entrada és un esquema, un host i un port opcional, sense camí, consulta ni comodí.
Utilitza https; http només s’accepta per a localhost, 127.0.0.1 i ::1.
Didit emmagatzema cada origen en minúscules i sense port per defecte, i retorna la llista a allowed_domains.
Una entrada no vàlida retorna un error 400 a allowed_domains.
Una llista nova substitueix la registrada, i una llista buida elimina la restricció.
Mentre la llista no estigui buida, POST /v3/session/ rebutja amb un 400 qualsevol callback web que no hi sigui, i el flux allotjat no redirigeix l’usuari a un callback emmagatzemat o per defecte del flux de treball que no hi sigui.
Els esquemes d’URL personalitzats (enllaços profunds d’aplicacions) i les crides API de servidor a servidor no es veuen afectats.Si envies endpoints, cada destinació del webhook que la llista no inclogui s’elimina de manera permanent, juntament amb el seu secret de signatura i tot el seu registre de lliuraments, exactament igual que DELETE /v3/webhook/destinations/{destination_uuid}/.
Això no es pot desfer.
Per gestionar les destinacions d’una en una, utilitza en lloc d’això els endpoints de destinació del webhook.