Saltar al contingut principal
L’API de Didit indica un error amb un codi d’estat HTTP i, en gairebé tots els casos, amb un cos en JSON. Aquesta pàgina enumera el significat de cada estat, l’aspecte del cos, els valors de code pels quals pots decidir una acció i els errors que es poden reintentar sense risc. Fia’t primer de l’estat i, si hi és, de code, perquè el text d’un missatge pot canviar.

Codis d’estat

Cossos d’error

Els cossos d’error no comparteixen un mateix format, així que llegeix-los de manera defensiva. La forma depèn de la família d’endpoints: Un 500 pot no tenir cap cos JSON, així que gestiona un cos que no es pot analitzar.

Errors de clau d’API

Durant uns minuts després d’eliminar una aplicació, l’API respon amb application_deleted, i després rebutja la clau com qualsevol clau incorrecta. No reintentis: l’aplicació i les seves claus ja no existeixen. Consulta Autenticació de l’API i Claus d’API per saber com funcionen les claus i els seus límits.

Crèdits insuficients

Cada família d’APIs informa d’un saldo baix de manera diferent: En un contracte, la creació de sessió respon amb 403 i "code": "contract_billing_suspended" mentre els serveis de pagament estiguin suspesos per a la teva organització. Les aplicacions de sandbox mai es facturen, així que no fan aquestes comprovacions.

Codis d’error

Aquests valors de code són estables, així que pots basar-hi la lògica del codi. La majoria apareixen al costat de detail; a la verificació amb carteres d’identitat digital, el codi és el valor de error.

Accés i facturació

Sol·licituds i idempotència

Comprovacions bancàries, de telèfon i de risc

Verificació d’empreses (KYB)

Carteres d’identitat digital

Informes i casos

Signatures electròniques

En crear la sessió, els problemes del document següents arriben com a valor del camp que els origina, amb estat 400, per exemple {"sign": "signature_document_changed"}:

Webhooks

Reintents i idempotència

Alguns errors es poden repetir amb seguretat i d’altres no:
  • 429: espera la capçalera Retry-After i, després, torna-ho a intentar.
  • 502 i 503: torna-ho a intentar amb retrocés quan la referència de l’endpoint indiqui que no s’ha facturat res, com passa amb les comprovacions de telèfon, correu electrònic, bancàries i de risc.
  • 502 en POST /v3/database-validation/: llegeix primer cada entrada de validation_errors, perquè aquest estat per si sol no significa un error temporal.
  • 503 en una eliminació: repeteix la mateixa sol·licitud fins que retorni 200.
  • Altres 4xx: corregeix primer la sol·licitud, perquè la mateixa sol·licitud fallarà de la mateixa manera.
POST /v3/aml/ i la verificació de cartera de Digital ID accepten una capçalera Idempotency-Key de fins a 255 caràcters. Si repeteixes una sol·licitud amb la mateixa clau i el mateix cos, es reprodueix la resposta emmagatzemada, de manera que l’operació i el càrrec s’executen una sola vegada. La mateixa clau amb un cos diferent respon amb 409, i mentre la primera sol·licitud encara s’està executant, els endpoints de cartera responen amb 409 i Retry-After. POST /v3/session/ no té cap clau d’idempotència, així que, si una creació supera el temps d’espera, llista les sessions per vendor_data abans de crear-ne una altra.

Relacionat

Darrera modificació el 7 de novembre del 2026