Przejdź do treści głównej
ShieldID

Dokumentacja API

Dokumentacja API weryfikacji tożsamości.

Każdy endpoint, który można wywołać, każde pole, które Państwo otrzymają w odpowiedzi, oraz co zrobić z webhookiem po jego nadejściu. W kwestii dokładnych typów pól źródłem prawdy jest aktualny dokument OpenAPI pod adresem /docs w Państwa własnym źródle API – ta strona jest wersją opisaną prostym językiem.

Bazowy adres URL i środowiska

Jeden bazowy adres URL. Dwa środowiska.

Każde żądanie trafia do tego samego hosta. To, w jakim środowisku Państwo działają, zależy wyłącznie od tego, który klucz API zostanie wysłany.

Każde żądanie w tej dokumentacji zakłada te dwie rzeczy.
Bazowy adres URL (ta dokumentacja)https://api.shieldid.ca — illustrative; your production API origin is published together with your API keys.
Nagłówek uwierzytelnianiaX-Api-Key: <Państwa klucz>, w każdym żądaniu z wyjątkiem dwóch publicznych punktów końcowych wskazanych poniżej.
Prefiks klucza sandboxvk_sand_… — sesje utworzone za pomocą tego klucza są oznaczane environment: "sandbox" i nigdy nie są rozliczane.
Prefiks klucza produkcyjnegovk_live_… — te same żądania, rozliczane zgodnie z Państwa planem.
Typ treściapplication/json w treści każdego żądania i odpowiedzi.

Punkty końcowe

Pełny zakres wersji v1.

Sześć punktów końcowych JSON oraz hostowana strona i publiczne sprawdzanie poświadczeń, które w ogóle nie korzystają z JSON — wystarczy umieścić do nich link.

Punkty końcowe JSON pod ścieżką /v1.
EndpointAuthWhat it does
POST /v1/sessionsX-Api-KeyTworzy sesję weryfikacji. Wymaga return_url i webhook_url. Zwraca session_id, verification_url oraz status: "PENDING".
GET /v1/sessions/{id}X-Api-KeyStatus i najważniejsze pola jednej sesji: status, confidence, environment.
GET /v1/sessions/{id}/resultX-Api-KeyPełny wynik po osiągnięciu przez sesję stanu VERIFIED lub FAILED: person, werdykty poszczególnych kontroli, confidence, verified_until.
DELETE /v1/sessions/{id}X-Api-KeyAnuluje sesję, która nadal ma stan PENDING lub IN_PROGRESS. Sesji w stanie VERIFIED, FAILED lub EXPIRED nie można anulować.
GET /v1/credentials/{token}None — publicSprawdza, czy zweryfikowane poświadczenie jest aktualnie ważne. Klucz API nie jest wymagany, dlatego można wywołać je z przeglądarki. Uwaga: obecna odpowiedź zawiera również imię i nazwisko zweryfikowanej osoby oraz typ i kraj dokumentu, a nie tylko informację o ważności — nie należy przekazywać tego linku osobie trzeciej, która nie powinna tych danych zobaczyć.
GET /v1/pricing/{country}X-Api-KeyCeny dla danego kraju na podstawie dwuliterowego kodu kraju ISO 3166-1.
Strony, do których Państwo kierują, a nie JSON do przetwarzania.
/v/{session_id}Hostowana strona weryfikacji — verification_url zwracany przez sesję. Na komputerze wyświetla kod QR; po jego zeskanowaniu telefon wnioskodawcy otrzymuje ten sam link, aby zrobić zdjęcie dokumentu i selfie.
/c/{session_id}Publiczna strona sprawdzania poświadczeń dla jednej zweryfikowanej sesji, niewymagająca uwierzytelnienia. Uwaga: obecna odpowiedź zawiera również imię i nazwisko zweryfikowanej osoby oraz typ i kraj dokumentu, a nie tylko informację o ważności — nie należy przekazywać tego linku osobie trzeciej, która nie powinna tych danych zobaczyć.
/docsAktualna, interaktywna dokumentacja OpenAPI dla źródła API Państwa konta.

Tworzenie sesji

POST /v1/sessions, od początku do końca.

Żądanie i dokładnie to, co wraca w odpowiedzi.

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 — pola żądania.
return_urlstring, wymagane — Adres, na który wnioskodawca zostaje przekierowany po zakończeniu. Musi być http lub https.
webhook_urlstring, wymagane — Adres, pod który dostarczany jest podpisany wynik. Zob. Webhooki poniżej.
expected_namestring, wymagane — Imię i nazwisko, które spodziewają się Państwo zobaczyć w dokumencie; służy do weryfikacji krzyżowej z treścią dokumentu tożsamości.
expected_dob / expected_addressstring, opcjonalne — Porównywane z dokumentem, jeśli zostaną podane; nie są wymagane do przeprowadzenia weryfikacji.
localestring, opcjonalne — "en" lub "fr". Ustawia język hostowanej strony widzianej przez wnioskodawcę.
metadataobject, opcjonalne — Własne dane referencyjne — identyfikator wniosku, identyfikator najemcy, cokolwiek, co ma zostać zwrócone bez zmian w wyniku i w webhooku.

Wynik

GET /v1/sessions/{id}/result — struktura odpowiedzi.

Taka sama struktura jest dostarczana w danych webhooka, więc rzadko kiedy trzeba w ogóle odpytywać ten punkt końcowy.

Pola najwyższego poziomu.
session_idIdentyfikator utworzonej sesji.
statusPENDING, IN_PROGRESS, VERIFIED, FAILED lub EXPIRED.
environment"sandbox" lub "production", zgodnie z kluczem, za pomocą którego utworzono sesję.
personPola odczytane z dokumentu: imię i nazwisko, data urodzenia, typ dokumentu, kraj i jurysdykcja dokumentu, adres.
checksJeden werdykt dla każdej kontroli – patrz niżej. Nigdy jeden nieprzejrzysty wynik.
confidenceJedna łączna wartość dla całej weryfikacji. Poszczególne kontrole, w tym dopasowanie twarzy, są nadal raportowane osobno względem ustalonego progu decyzyjnego – to pole ich nie zastępuje.
verified_untilJak długo wynik jest uznawany za aktualny, w sesji ze statusem VERIFIED.
failure_reasonUstawiane w sesji ze statusem FAILED – na przykład FACE_MATCH_BELOW_THRESHOLD lub CANCELLED_BY_API. W pozostałych przypadkach null.
metadataDokładnie to, co zostało wysłane podczas tworzenia sesji, bez zmian.
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 i checks.face_match przyjmują wartość PASS, FAIL lub SKIPPED. Weryfikacja list obserwacyjnych (checks.sanctions – CLEAR, MATCH lub SKIPPED) jest dodatkiem i pojawia się tylko na kontach, które ją włączyły.

Cykl życia sesji

Pięć stanów, jedna ścieżka.

Sesja przechodzi dalej samoczynnie; nie sterują Państwo automatem stanów, a jedynie odczytują jego stan.

Wartości status, w kolejności.
PENDINGUtworzona. Nikt jeszcze nie otworzył verification_url.
IN_PROGRESSWnioskodawca otworzył link i znajduje się gdzieś w procesie przechwytywania.
VERIFIEDWszystkie kontrole zostały wykonane, a wynik jest gotowy. Stan końcowy – proszę wywołać endpoint wyniku lub odczytać webhook.
FAILEDCo najmniej jedna kontrola nie zakończyła się powodzeniem. failure_reason wskazuje, która. Wkrótce: ponowienie, które resetuje sesję do stanu PENDING – do tego czasu proszę traktować FAILED jako stan końcowy i utworzyć nową sesję, jeśli wnioskodawca chce spróbować ponownie.
EXPIREDNikt nie zdążył zakończyć procesu. Sesje wygasają automatycznie po domyślnym czasie (30 minut); aby spróbować ponownie, proszę utworzyć nową.

DELETE /v1/sessions/{id} wcześniej anuluje sesję w stanie PENDING lub IN_PROGRESS. Sesji, która osiągnęła już stan VERIFIED, FAILED lub EXPIRED, nie można anulować — jest już zakończona.

Błędy

Na co należy się przygotować.

To krótka lista tego, pod co warto już dziś pisać kod. Pełny, aktualny zestaw kodów błędów i ładunków jest opisany w aktualnym dokumencie OpenAPI pod adresem /docs.

Status HTTP, kod błędu i jego znaczenie.
StatusCodeMeaning
401UNAUTHORIZEDBrak nagłówka X-Api-Key.
401INVALID_KEY_FORMATKlucz nie zaczyna się od vk_sand_ ani vk_live_ albo nie odpowiada żadnemu kluczowi na koncie.
403FORBIDDENKlucz jest prawidłowy, ale nie ma dostępu do sesji lub zasobu, o który Państwo proszą.
404NOT_FOUNDNie istnieje sesja, poświadczenie ani zasób o tym identyfikatorze.
409CONFLICTSesja nie jest w stanie, który pozwala na to działanie — na przykład próba anulowania sesji, która ma już stan VERIFIED.
422VALIDATION_ERRORBrakuje wymaganego pola lub jest ono nieprawidłowe – na przykład return_url nie jest prawidłowym adresem URL http lub https.

Webhooki

Podpisane, dostarczone, ponawiane.

Gdy sesja osiągnie stan VERIFIED lub FAILED, ShieldID wysyła metodą POST strukturę opisaną powyżej na Państwa webhook_url.

  • Dostarczany jako POST z treścią JSON zgodną ze strukturą wyniku przedstawioną powyżej.
  • Podpisany algorytmem HMAC-SHA256 na podstawie surowej treści żądania i przesyłany w nagłówku X-Bio-Signature. Przed zaufaniem ładunkowi proszę zweryfikować podpis względem sekretu webhooka.
  • Ponawiany do trzech razy z liniowym opóźnieniem, jeśli Państwa endpoint nie odpowie statusem 2xx.
  • Wkrótce: ponowienie sesji FAILED, które po rozstrzygnięciu dostarczy drugi webhook. Na dziś zasadą jest jeden webhook na sesję.
  • Nazwy pól w tej dokumentacji są zgodne z jej treścią. Jeśli to, co faktycznie docierand wygląda inaczej, proszę zaufać rzeczywistemu ładunkowi, a nie tej stronie, i dać nam znać – lista pól jest dostosowywana do API, a nie odwrotnie.

Weryfikacja podpisu

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");
});

Idempotentność i ponowienia

Proszę budować procedury obsługi, które można bezpiecznie uruchomić dwukrotnie.

Na razie nie ma dedykowanego klucza idempotentności – ani przy tworzeniu sesji, ani przy dostarczaniu webhooka.

  • Ponowione dostarczenie webhooka może dotrzeć więcej niż raz dla tej samej sesji. Proszę oprzeć procedurę obsługi na parze session_id + status i zadbać o to, aby zapis wyniku był idempotentny.
  • Nie należy bezrefleksyjnie ponawiać POST /v1/sessions po przekroczeniu limitu czasu – proszę najpierw sprawdzić, czy sesja została utworzona, w przeciwnym razie można otrzymać dwie sesje dla jednego wnioskodawcy.
  • Planowany jest dedykowany nagłówek Idempotency-Key dla tworzenia sesji.

WkrótceObsługa Idempotency-Key przy tworzeniu sesji

Na bieżąco

Ta dokumentacja się zmienia. Proszę śledzić dziennik zmian.

Dodania pól, nowe kody błędów i zmiany endpointów są ogłaszane tam, zanim pojawią się tutaj.

Pytania

FAQ do dokumentacji.

Dalej

Wykorzystajcie Państwo tę dokumentację w praktyce.

Proszę postępować zgodnie z przewodnikiem szybkiego startu, aby krok po kroku przejść od klucza sandbox do zweryfikowanej sesji i podpisanego webhooka.