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.
| Bazowy adres URL (ta dokumentacja) | https://api.shieldid.ca — illustrative; your production API origin is published together with your API keys. |
|---|---|
| Nagłówek uwierzytelniania | X-Api-Key: <Państwa klucz>, w każdym żądaniu z wyjątkiem dwóch publicznych punktów końcowych wskazanych poniżej. |
| Prefiks klucza sandbox | vk_sand_… — sesje utworzone za pomocą tego klucza są oznaczane environment: "sandbox" i nigdy nie są rozliczane. |
| Prefiks klucza produkcyjnego | vk_live_… — te same żądania, rozliczane zgodnie z Państwa planem. |
| Typ treści | application/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.
| Endpoint | Auth | What it does |
|---|---|---|
| POST /v1/sessions | X-Api-Key | Tworzy sesję weryfikacji. Wymaga return_url i webhook_url. Zwraca session_id, verification_url oraz status: "PENDING". |
| GET /v1/sessions/{id} | X-Api-Key | Status i najważniejsze pola jednej sesji: status, confidence, environment. |
| GET /v1/sessions/{id}/result | X-Api-Key | Peł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-Key | Anuluje 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 — public | Sprawdza, 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-Key | Ceny dla danego kraju na podstawie dwuliterowego kodu kraju ISO 3166-1. |
| /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ć. |
| /docs | Aktualna, 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.
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" }
}'| return_url | string, wymagane — Adres, na który wnioskodawca zostaje przekierowany po zakończeniu. Musi być http lub https. |
|---|---|
| webhook_url | string, wymagane — Adres, pod który dostarczany jest podpisany wynik. Zob. Webhooki poniżej. |
| expected_name | string, 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_address | string, opcjonalne — Porównywane z dokumentem, jeśli zostaną podane; nie są wymagane do przeprowadzenia weryfikacji. |
| locale | string, opcjonalne — "en" lub "fr". Ustawia język hostowanej strony widzianej przez wnioskodawcę. |
| metadata | object, 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.
| session_id | Identyfikator utworzonej sesji. |
|---|---|
| status | PENDING, IN_PROGRESS, VERIFIED, FAILED lub EXPIRED. |
| environment | "sandbox" lub "production", zgodnie z kluczem, za pomocą którego utworzono sesję. |
| person | Pola odczytane z dokumentu: imię i nazwisko, data urodzenia, typ dokumentu, kraj i jurysdykcja dokumentu, adres. |
| checks | Jeden werdykt dla każdej kontroli – patrz niżej. Nigdy jeden nieprzejrzysty wynik. |
| confidence | Jedna łą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_until | Jak długo wynik jest uznawany za aktualny, w sesji ze statusem VERIFIED. |
| failure_reason | Ustawiane w sesji ze statusem FAILED – na przykład FACE_MATCH_BELOW_THRESHOLD lub CANCELLED_BY_API. W pozostałych przypadkach null. |
| metadata | Dokładnie to, co zostało wysłane podczas tworzenia sesji, bez zmian. |
{
"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.
| PENDING | Utworzona. Nikt jeszcze nie otworzył verification_url. |
|---|---|
| IN_PROGRESS | Wnioskodawca otworzył link i znajduje się gdzieś w procesie przechwytywania. |
| VERIFIED | Wszystkie kontrole zostały wykonane, a wynik jest gotowy. Stan końcowy – proszę wywołać endpoint wyniku lub odczytać webhook. |
| FAILED | Co 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. |
| EXPIRED | Nikt 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 | Code | Meaning |
|---|---|---|
| 401 | UNAUTHORIZED | Brak nagłówka X-Api-Key. |
| 401 | INVALID_KEY_FORMAT | Klucz nie zaczyna się od vk_sand_ ani vk_live_ albo nie odpowiada żadnemu kluczowi na koncie. |
| 403 | FORBIDDEN | Klucz jest prawidłowy, ale nie ma dostępu do sesji lub zasobu, o który Państwo proszą. |
| 404 | NOT_FOUND | Nie istnieje sesja, poświadczenie ani zasób o tym identyfikatorze. |
| 409 | CONFLICT | Sesja nie jest w stanie, który pozwala na to działanie — na przykład próba anulowania sesji, która ma już stan VERIFIED. |
| 422 | VALIDATION_ERROR | Brakuje 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
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.