Primers passos
Integració / SDK
Verificació d'usuaris
Verificació d'empreses
Monitoratge de transaccions
Registre de canvisvin o bank_account_number, així que les pàgines de servei que els envien només mostren cURL.
Instal·lació
Configuració
Cada SDK llegeix les mateixes variables d’entorn, de manera que un client creat sense opcions ja està a punt per usar-se. Els entorns edge no tenen entorn de procés: en aquests casos, passa la clau d’API al client de Node.js com a opció.
Tot el que pots definir des de l’entorn també ho pots passar al client, juntament amb l’URL base, el temps d’espera, els reintents, les capçaleres per defecte i el teu propi client HTTP. Crea un client per procés i comparteix-lo: manté un pool de connexions i és segur d’usar des de diversos fils o tasques.
Els mètodes
account (registre programàtic: registre, inici de sessió, organitzacions i aplicacions) criden https://apx.didit.me/auth/v2 i mai no envien la teva clau d’API. Inicia sessió amb account.login i després passa el token d’accés retornat al client com a token de compte.
Què fa cada SDK
- Recursos i mètodes. Les crides segueixen els recursos de l’API:
client.<resource>.<method>(...), per exemplesessions.create,sessions.retrieve_decisionotransactions.create, amb la capitalització de cada llenguatge. Els identificadors de ruta són arguments posicionals; el cos i la consulta són un sol conjunt de camps amb nom. Python, Node.js, PHP i Ruby usen els noms de camp de l’API (workflow_id); Go, Java i .NET usen la capitalització del seu llenguatge (WorkflowID,workflowId,WorkflowId). - Llistes. Els mètodes de llista recorren tots els resultats per tu (
limitioffsetper sota), i també exposen cada pàgina ambcount,next,previousiresults. En Ruby,auto_paging_eachrecorre totes les pàgines, itotal_count,next_urliprevious_urld’una pàgina són elscount,nextipreviousde l’API. - Fitxers. Les pujades (imatges de documents, selfies, comprovant de domicili, importacions) accepten una ruta, bytes o un flux. Les descàrregues (PDF de sessions, informes) retornen bytes o un flux, mai JSON analitzat.
- Compatibilitat cap endavant. Un camp de resposta o un valor d’enumeració que la versió del SDK encara no coneix es conserva i és llegible, mai no és un error, així que una addició de l’API no trenca una integració desplegada.
- Webhooks.
webhooks.verifycomprova les capçaleresX-Signature-V2iX-Signaturei la marca de temps d’un lliurament amb el teu secret del webhook, i retorna un esdeveniment tipat. Accepta una llista de secrets mentre en rotes un. Consulta Webhooks per a l’esquema de signatura. - Autenticació. Un ajudant
Authenticationverifica els tokens d’accés i d’ID que signa el teu emissor d’Authentication, i crida els seus endpoints de token, sessió i step-up. Mai no usa la teva clau d’API.
Errors, reintents i temps límit
Tots els errors deriven de
DiditError. En Go, tots els errors implementen la interfície didit.Error i són de tipus punter, com *didit.NotFoundError. Java, PHP i .NET els anomenen amb el sufix habitual Exception i escriuen API com a Api: DiditException, ApiStatusException, NotFoundException.
Els SDK reintenten una sol·licitud fallida fins a 2 vegades, amb un retard exponencial a partir de 0,5 segons (aleatorietat completa, com a màxim 8 segons) i respectant la capçalera Retry-After. GET, HEAD, PUT i DELETE es reintenten en cas d’errors de connexió, temps límit, 408, 429 i 5xx. POST i PATCH només es reintenten en cas de 429 o quan la connexió ha fallat abans d’enviar la sol·licitud, de manera que un reintent mai no crea una segona sessió ni una segona transacció. El temps límit per defecte és de 60 segons. Cada resposta també exposa l’estat HTTP en brut, les capçaleres i l’identificador de la sol·licitud. Consulta Límit de freqüència per conèixer els límits que hi ha darrere del 429.
Versions i suport
- Els SDK segueixen el versionat semàntic, amb una regla per als canvis de l’API. Un canvi que reflecteix l’API de Didit es publica com a versió menor, fins i tot quan pot trencar el codi tipat (un camp amb un tipus canviat, un camp que ara pot ser nul, o un endpoint, un camp o un valor d’enumeració eliminat): l’API ja es comporta així per a tots els clients, de manera que una versió anterior de l’SDK no és més segura. Les notes de la versió enumeren aquests canvis sota “Canvis de l’API que poden trencar el codi tipat”.
- Una versió major només es fa per a un canvi en el disseny del propi SDK: un mètode o un recurs reanomenat o eliminat mentre l’API el manté, un canvi en la configuració del client, en els errors, en els reintents, en la paginació o en el comportament de la verificació de webhooks, o l’eliminació d’una versió d’entorn d’execució. Quan un endpoint surt de l’API o un dels seus mètodes es reanomena, el mètode antic es manté durant almenys una versió menor més, marcat com a obsolet, perquè el teu codi continuï compilant mentre migres al nou mètode. Cada llenguatge manté el seu propi número de versió: Node.js, PHP i Ruby estan a la 2.x i la resta a la 1.x, perquè aquests tres van publicar un canvi de l’API com a versió major abans que s’apliqués aquesta regla.
- Es generen a partir del contracte d’API publicat (
openapi-25.jsoniopenapi-auth.json), i els seus mètodes de Didit Authentication es comproven ambopenapi-authentication.json. Les tres fonts es comproven cada dia, de manera que un endpoint o un camp nou arriba en una versió regular dels set SDK. - Cada SDK és compatible amb l’entorn d’execució mínim de la taula i amb totes les versions posteriors. Les seves proves s’executen amb el mínim i amb cada versió posterior o, per a Node.js i Java, amb cada versió de suport a llarg termini.
- El fitxer
CHANGELOG.mdde cada repositori enumera els canvis de cada versió. - Informa d’un problema de seguretat de forma privada mitjançant els avisos de seguretat del repositori de l’SDK o a support@didit.me.