Vai al contenuto principale
ShieldID

Riferimento API

Il riferimento API per la verifica dell'identità.

Ogni endpoint che può chiamare, ogni campo che riceverà e cosa fare con un webhook una volta arrivato. Per i tipi esatti dei campi, consideri fonte di verità il documento OpenAPI live su /docs nella Sua origine API: questa pagina ne è la versione in linguaggio semplice.

URL di base e ambienti

Un solo URL di base. Due ambienti.

Ogni richiesta va allo stesso host. L'ambiente in cui Lei si trova è deciso interamente dalla chiave API che invia.

Ogni richiesta in questo riferimento presuppone questi due elementi.
URL di base (questa documentazione)https://api.shieldid.ca — illustrative; your production API origin is published together with your API keys.
Intestazione di autenticazioneX-Api-Key: <la Sua chiave>, su ogni richiesta tranne i due endpoint pubblici indicati di seguito.
Prefisso della chiave sandboxvk_sand_… — le sessioni create con questa chiave vengono contrassegnate con environment: "sandbox" e non vengono mai fatturate.
Prefisso della chiave di produzionevk_live_… — le stesse richieste, addebitate secondo il Suo piano.
Tipo di contenutoapplication/json su ogni corpo di richiesta e risposta.

Endpoint

L'intera superficie della v1.

Sei endpoint JSON, più una pagina ospitata e un controllo pubblico delle credenziali che non sono affatto JSON: basta inserirne il link.

Endpoint JSON sotto /v1.
EndpointAuthWhat it does
POST /v1/sessionsX-Api-KeyCrea una sessione di verifica. Richiede un return_url e un webhook_url. Restituisce session_id, verification_url e status: "PENDING".
GET /v1/sessions/{id}X-Api-KeyStato e campi principali di una sessione: status, confidence, environment.
GET /v1/sessions/{id}/resultX-Api-KeyIl risultato completo una volta che una sessione raggiunge VERIFIED o FAILED: persona, esiti per singolo controllo, confidence, verified_until.
DELETE /v1/sessions/{id}X-Api-KeyAnnulla una sessione ancora PENDING o IN_PROGRESS. Una sessione già VERIFIED, FAILED o EXPIRED non può essere annullata.
GET /v1/credentials/{token}None — publicVerifica se una credenziale verificata è attualmente valida. Non richiede alcuna chiave API, quindi può essere chiamato da un browser. Nota: la risposta attuale include anche il nome della persona verificata e il tipo/paese del documento, non soltanto un indicatore valido/non valido: non condivida questo link con una terza parte a cui non desidera mostrare tali dati.
GET /v1/pricing/{country}X-Api-KeyPrezzi per paese per un codice paese ISO 3166-1 di due lettere.
Pagine da collegare, non JSON da analizzare.
/v/{session_id}La pagina di verifica ospitata — il verification_url restituito da una sessione. Su desktop mostra un codice QR; scansionandolo, il telefono del richiedente riceve lo stesso link per acquisire documento e selfie.
/c/{session_id}Una pagina pubblica, senza autenticazione, per il controllo della credenziale di una sessione verificata. Nota: la risposta attuale include anche il nome della persona verificata e il tipo/paese del documento, non soltanto un indicatore valido/non valido: non condivida questo link con una terza parte a cui non desidera mostrare tali dati.
/docsIl riferimento OpenAPI interattivo e in tempo reale per l'origine API del Suo account.

Creazione di una sessione

POST /v1/sessions, passo dopo passo.

La richiesta e che cosa viene restituito esattamente.

bash
curl -X POST https://api.shieldid.ca/v1/sessions \
  -H "X-Api-Key: vk_sand_your_key" \
  -H "Content-Type: application/json" \
  -d '{
    "return_url": "https://yourapp.example/verified",
    "webhook_url": "https://yourapp.example/hooks/shieldid",
    "expected_name": "Jordan Smith",
    "locale": "en",
    "metadata": { "application_id": "app_9182" }
  }'

POST /v1/sessions — campi della richiesta.
return_urlstring, obbligatorio — Dove viene reindirizzato il richiedente al termine. Deve essere http o https.
webhook_urlstring, obbligatorio — Dove viene consegnato il risultato firmato. Veda Webhook più avanti.
expected_namestring, obbligatorio — Il nome atteso sul documento, utilizzato per confrontarlo con quanto riportato effettivamente dal documento d'identità.
expected_dob / expected_addressstring, facoltativo — Viene confrontato con il documento se fornito; non è necessario per eseguire una verifica.
localestring, facoltativo — "en" o "fr". Imposta la lingua della pagina ospitata che il richiedente visualizza.
metadataobject, facoltativo — I Suoi dati di riferimento — un id di pratica, un id di tenant, qualsiasi dato che desideri ricevere invariato nel risultato e nel webhook.

Il risultato

GET /v1/sessions/{id}/result — struttura della risposta.

La stessa struttura viene consegnata nel payload del webhook, quindi raramente è necessario interrogare questo endpoint.

Campi di primo livello.
session_idL'id che ha creato.
statusPENDING, IN_PROGRESS, VERIFIED, FAILED o EXPIRED.
environment"sandbox" o "production", in corrispondenza della chiave che ha creato la sessione.
personI campi letti dal documento: nome, data di nascita, tipo di documento, paese e giurisdizione del documento, indirizzo.
checksUn verdetto per ciascun controllo — vedere sotto. Mai un unico punteggio opaco.
confidenceUn unico valore complessivo per la verifica. I singoli controlli, compreso il confronto del volto, sono comunque riportati separatamente rispetto a una soglia decisionale fissa: questo campo non li sostituisce.
verified_untilPer quanto tempo il risultato è considerato aggiornato, in una sessione VERIFIED.
failure_reasonImpostato in una sessione FAILED — ad esempio FACE_MATCH_BELOW_THRESHOLD o CANCELLED_BY_API. Altrimenti null.
metadataTutto ciò che ha inviato al momento della creazione della sessione, invariato.
json
{
  "session_id": "ses_9f2c1a",
  "status": "VERIFIED",
  "environment": "sandbox",
  "person": {
    "name": "Jordan Smith",
    "dob": "1994-03-11",
    "document_type": "drivers_licence",
    "document_country": "CA",
    "document_jurisdiction": "ON"
  },
  "checks": {
    "document": "PASS",
    "liveness": "PASS",
    "antispoof": "PASS",
    "face_match": "PASS"
  },
  "confidence": 88,
  "verified_until": "2027-03-11T00:00:00Z",
  "failure_reason": null,
  "metadata": { "application_id": "app_9182" }
}

Add-onchecks.document, checks.liveness, checks.antispoof e checks.face_match risultano ciascuno in PASS, FAIL o SKIPPED. Il controllo delle liste di sorveglianza (checks.sanctions — CLEAR, MATCH o SKIPPED) è un componente aggiuntivo e compare solo per gli account che lo attivano.

Ciclo di vita della sessione

Cinque stati, un solo percorso.

Una sessione avanza da sola; Lei non governa la macchina a stati, la legge soltanto.

Valori di status, in ordine.
PENDINGCreata. Nessuno ha ancora aperto il verification_url.
IN_PROGRESSIl richiedente ha aperto il link e si trova in un punto del flusso di acquisizione.
VERIFIEDTutti i controlli sono stati eseguiti e il risultato è pronto. Stato finale: chiami l'endpoint del risultato oppure legga il webhook.
FAILEDAlmeno un controllo non è stato superato. failure_reason indica quale. Prossimamente: un nuovo tentativo che riporta la sessione a PENDING — fino ad allora, consideri FAILED uno stato finale e crei una nuova sessione se il richiedente desidera riprovare.
EXPIREDNessuno ha completato in tempo. Le sessioni scadono automaticamente dopo un intervallo predefinito (30 minuti); ne crei una nuova per riprovare.

DELETE /v1/sessions/{id} annulla in anticipo una sessione PENDING o IN_PROGRESS. Una sessione che ha già raggiunto lo stato VERIFIED, FAILED o EXPIRED non può essere annullata: è già conclusa.

Errori

Cosa prevedere.

Questo è l'elenco ristretto su cui vale la pena basare oggi il codice. L'insieme completo e aggiornato di codici di errore e payload è documentato nell'OpenAPI live all'indirizzo /docs.

Stato HTTP, codice di errore e significato.
StatusCodeMeaning
401UNAUTHORIZEDManca l'intestazione X-Api-Key.
401INVALID_KEY_FORMATLa chiave non inizia con vk_sand_ o vk_live_, oppure non corrisponde a nessuna chiave dell'account.
403FORBIDDENLa chiave è valida ma non ha accesso alla sessione o alla risorsa richiesta.
404NOT_FOUNDNon esiste alcuna sessione, credenziale o risorsa con quell'id.
409CONFLICTLa sessione non si trova in uno stato che consenta l'azione, ad esempio l'annullamento di una sessione già VERIFIED.
422VALIDATION_ERRORUn campo obbligatorio manca o è malformato — ad esempio, return_url non è un URL http o https valido.

Webhook

Firmato, consegnato, ritentato.

Quando una sessione raggiunge VERIFIED o FAILED, ShieldID invia con POST la struttura documentata sopra al Suo webhook_url.

  • Consegnato come POST con un corpo JSON conforme alla struttura del risultato indicata sopra.
  • Firmato con HMAC-SHA256 sul corpo grezzo della richiesta, inviato in un'intestazione X-Bio-Signature. Lo verifichi con il Suo segreto del webhook prima di fidarsi del payload.
  • Ritentato fino a tre volte con backoff lineare se il Suo endpoint non risponde con uno stato 2xx.
  • Prossimamente: un nuovo tentativo per le sessioni FAILED che consegna un secondo webhook non appena si risolve. Oggi, consideri come regola un solo webhook per sessione.
  • I nomi dei campi qui riportati corrispondono a questo riferimento. Se ciò che arriva effettivamente appare diverso, si fidi del payload reale più che di questa pagina e ce lo segnali: l'elenco dei campi viene mantenuto allineato all'API, non viceversa.

Verificare la firma

javascript
import crypto from "node:crypto";

function isValidShieldIdSignature(rawBody, signatureHeader, secret) {
  const expected = crypto.createHmac("sha256", secret).update(rawBody).digest("hex");
  const provided = signatureHeader || "";
  const a = Buffer.from(expected, "hex");
  const b = Buffer.from(provided, "hex");
  return a.length === b.length && crypto.timingSafeEqual(a, b);
}

// rawBody must be the exact, unparsed request body
app.post("/hooks/shieldid", express.raw({ type: "application/json" }), (req, res) => {
  const ok = isValidShieldIdSignature(req.body, req.headers["x-bio-signature"], process.env.SHIELDID_WEBHOOK_SECRET);
  if (!ok) return res.status(401).send("invalid signature");

  const result = JSON.parse(req.body);
  // result.session_id, result.status, result.checks, …
  res.status(200).send("ok");
});

Idempotenza e nuovi tentativi

Realizzi gestori che siano sicuri anche se eseguiti due volte.

Non esiste ancora una chiave di idempotenza dedicata, né per la creazione della sessione né per la consegna dei webhook.

  • Una consegna di webhook ritentata può arrivare più di una volta per la stessa sessione. Basi il Suo gestore su session_id + status e renda idempotente la scrittura del risultato.
  • Non ritenti POST /v1/sessions alla cieca in caso di timeout: verifichi prima se la sessione è stata creata, altrimenti potrebbe ritrovarsi con due sessioni per un solo richiedente.
  • È prevista un'intestazione Idempotency-Key dedicata per la creazione della sessione.

ProssimamenteSupporto di Idempotency-Key nella creazione della sessione

Restare aggiornati

Questo riferimento cambia. Segua il changelog.

Aggiunte di campi, nuovi codici di errore e modifiche agli endpoint vengono annunciati lì prima di arrivare qui.

Domande

FAQ sul riferimento.

Avanti

Metta in pratica questo riferimento.

Segua la guida rapida per passare, in ordine, da una chiave sandbox a una sessione verificata e a un webhook firmato.