Standalone tools

The /v3/tools/* endpoints mirror the console's Manual Tools. They are stateless: none of them create or mutate a verification session. Each is tenant-scoped by your API key (x-api-key), and image arguments are base64 strings — raw or a data: URI.

Conventions

• Auth: x-api-key: <tenant_api_key> (or X-API-Key). See Authentication.
• Images: base64 (optionally a data: URI), JPEG or PNG only, max 8 MB. Other formats (HEIC, WEBP, GIF, …) return 415 unsupported_image_type; a missing/undecodable image returns 400 <field>_required / 400 invalid_<field>.
• Rate limit: the tools share a per-tenant bucket of 120 requests/minute (kyc_v3_tools). Over-limit requests get 429.
• Entitlement + billing: each chargeable tool is gated by your plan. A disabled feature returns 403 feature_not_enabled (with a features array); an empty balance returns 402 insufficient_credits. A successful call debits one use at your plan's rate for the tool; failed calls are free. Send an Idempotency-Key header to make retries safe — a repeat of the same request (same key and body, same UTC day) isn't charged twice.
• Errors: /v3 tool errors return { "detail": "<code>" } with the HTTP status carrying the machine signal. Branch on status + the stable code, not the message.

AML check

Ad-hoc watchlist screening for a name — the same engine as the AML_SCREENING module. A name is the minimum useful selector; every other field narrows the candidate set.

curl -X POST "$TF_BASE_URL/v3/tools/aml-check/" \
  -H "x-api-key: $TF_API_KEY" -H "Content-Type: application/json" \
  -d '{
        "full_name": "Aarav Sharma",
        "date_of_birth": "1990-04-12",
        "nationality": "NP",
        "lists": ["sanctions", "pep"],
        "match_threshold": 0.7
      }'

const res = await fetch(`${process.env.TF_BASE_URL}/v3/tools/aml-check/`, {
  method: "POST",
  headers: {
    "x-api-key": process.env.TF_API_KEY!,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    full_name: "Aarav Sharma",
    date_of_birth: "1990-04-12",
    nationality: "NP",
    lists: ["sanctions", "pep"],
    match_threshold: 0.7,
  }),
});
const screen = await res.json();
console.log(screen.risk_level, screen.matches.length);

import requests

res = requests.post(
    f"{BASE_URL}/v3/tools/aml-check/",
    headers={"x-api-key": API_KEY},
    json={
        "full_name": "Aarav Sharma",
        "date_of_birth": "1990-04-12",
        "nationality": "NP",
        "lists": ["sanctions", "pep"],
        "match_threshold": 0.7,
    },
    timeout=30,
)
screen = res.json()
print(screen["risk_level"], len(screen["matches"]))

{
  "risk_level": "medium",
  "matches": [],
  "possible_matches": [
    {
      "entity_id": "NK-9x2",
      "name": "Aarav Sharma",
      "schema": "Person",
      "score": 0.63,
      "match": false,
      "lists": ["pep"],
      "topics": ["role.pep"],
      "datasets": ["everypolitician"],
      "birth_date": "",
      "countries": ["np"],
      "aliases": [],
      "nationalities": ["np"],
      "positions": ["Member of Parliament"],
      "gender": "male",
      "addresses": [],
      "id_numbers": [],
      "url": ""
    }
  ],
  "informational_matches": [],
  "lists_checked": ["pep", "sanctions"],
  "provider": "watchlist",
  "dataset": "default",
  "algorithm": "logic-v1",
  "threshold": 0.7
}

risk_level is high / medium / low / clear. A query with no name returns 400 name_required; an unreachable engine returns 503 screening_unavailable. Full field reference, list topics, scoring tiers and the corroboration rule: AML screening.

Face search

Ranks your tenant's enrolled identities whose face matches a probe photo — duplicate-account detection. Read-only (nothing is flagged); it mirrors the automatic duplicate check.

The gallery it searches holds selfies captured live during a session and photos enrolled from outside — bulk-imported through identity import or enrolled one at a time with face enroll — document portraits and liveness stills stay out of it. If you imported an existing customer base, create each returning customer's session with vendor_data set to the id they were imported under: verifying without it spawns a second identity that the duplicate check then flags against their own imported record. See importing existing identities.

curl -X POST "$TF_BASE_URL/v3/tools/face-search/" \
  -H "x-api-key: $TF_API_KEY" -H "Content-Type: application/json" \
  -d '{"image_base64":"<jpg/png base64>","threshold":0.35,"top_k":12}'

const res = await fetch(`${process.env.TF_BASE_URL}/v3/tools/face-search/`, {
  method: "POST",
  headers: {
    "x-api-key": process.env.TF_API_KEY!,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({ image_base64: imageB64, threshold: 0.35, top_k: 12 }),
});
const { matches } = await res.json();
console.log(matches.map((m: any) => [m.external_user_id, m.score]));

import requests

res = requests.post(
    f"{BASE_URL}/v3/tools/face-search/",
    headers={"x-api-key": API_KEY},
    json={"image_base64": image_b64, "threshold": 0.35, "top_k": 12},
    timeout=30,
)
for m in res.json()["matches"]:
    print(m["external_user_id"], m["score"])

{
  "matches": [
    {
      "individual_id": "9f3a…",
      "name": "Aarav Sharma",
      "external_user_id": "user-123",
      "status": "active",
      "kyc_status": "clear",
      "score": 0.71,
      "thumb": "https://…/face.jpg"
    }
  ],
  "threshold": 0.35
}

422 no_face_detected if there's no usable face in the probe.

Signature verify

Compares a probe signature to a reference — structural similarity of stroke geometry (not pen dynamics). Both inputs are cropped to just the signature ink first, so a full document photo or a video frame is matched on its ink, not the surroundings.

curl -X POST "$TF_BASE_URL/v3/tools/signature-verify/" \
  -H "x-api-key: $TF_API_KEY" -H "Content-Type: application/json" \
  -d '{"reference_base64":"<base64>","probe_base64":"<base64>","threshold":0.62}'

const res = await fetch(`${process.env.TF_BASE_URL}/v3/tools/signature-verify/`, {
  method: "POST",
  headers: {
    "x-api-key": process.env.TF_API_KEY!,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    reference_base64: referenceB64,
    probe_base64: probeB64,
    threshold: 0.62,
  }),
});
const out = await res.json();
console.log(out.verdict, out.score);

import requests

res = requests.post(
    f"{BASE_URL}/v3/tools/signature-verify/",
    headers={"x-api-key": API_KEY},
    json={"reference_base64": reference_b64, "probe_base64": probe_b64, "threshold": 0.62},
    timeout=30,
)
out = res.json()
print(out["verdict"], out["score"])

{
  "score": 0.68,
  "verdict": "match",
  "matched": true,
  "threshold": 0.62
}

The verdict is derived against the requested threshold:

Signature search (beta)

Ranks your tenant's enrolled signature specimens against a probe — a recall aid for operators, not a verdict. The probe is cropped to the signature ink first, the same treatment enrollment applies, so both sides of the search are built from the same kind of crop.

curl -X POST "$TF_BASE_URL/v3/tools/signature-search/" \
  -H "x-api-key: $TF_API_KEY" -H "Content-Type: application/json" \
  -d '{"image_base64":"<png base64>","threshold":0.6,"top_k":12}'

const res = await fetch(`${process.env.TF_BASE_URL}/v3/tools/signature-search/`, {
  method: "POST",
  headers: {
    "x-api-key": process.env.TF_API_KEY!,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({ image_base64: imageB64, threshold: 0.6, top_k: 12 }),
});
const { matches, beta } = await res.json();
console.log(beta, matches.length);

import requests

res = requests.post(
    f"{BASE_URL}/v3/tools/signature-search/",
    headers={"x-api-key": API_KEY},
    json={"image_base64": image_b64, "threshold": 0.6, "top_k": 12},
    timeout=30,
)
data = res.json()
print(data["beta"], len(data["matches"]))

{
  "matches": [
    {
      "individual_id": "9f3a…",
      "name": "Aarav Sharma",
      "external_user_id": "user-123",
      "status": "active",
      "score": 0.64,
      "thumb": "https://…/signature.png"
    }
  ],
  "threshold": 0.6,
  "beta": true
}

422 no_signature_detected if the probe has no readable signature. Confirm any hit with the 1:1 signature verify.

Signature enroll

Attaches a reference signature to an identity so it becomes searchable by signature search. The input is cropped to the signature ink first, so a full video frame / document photo enrolls a clean specimen.

curl -X POST "$TF_BASE_URL/v3/tools/signature-enroll/" \
  -H "x-api-key: $TF_API_KEY" -H "Content-Type: application/json" \
  -d '{"external_user_id":"user-123","image_base64":"<png base64>","label":"account-opening"}'

const res = await fetch(`${process.env.TF_BASE_URL}/v3/tools/signature-enroll/`, {
  method: "POST",
  headers: {
    "x-api-key": process.env.TF_API_KEY!,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    external_user_id: "user-123",
    image_base64: imageB64,
    label: "account-opening",
  }),
});
const out = await res.json(); // 201
console.log(out.sample_id, out.individual_id);

import requests

res = requests.post(
    f"{BASE_URL}/v3/tools/signature-enroll/",
    headers={"x-api-key": API_KEY},
    json={
        "external_user_id": "user-123",
        "image_base64": image_b64,
        "label": "account-opening",
    },
    timeout=30,
)
out = res.json()  # 201
print(out["sample_id"], out["individual_id"])

{
  "sample_id": "c2b8…",
  "individual_id": "9f3a…"
}

On success returns 201. An unknown person returns 404 individual_not_found; an image with no readable signature returns 422 no_signature_detected.

Face enroll

Adds one face to your tenant's 1:N gallery so face search and the automatic duplicate check can find the person — the face counterpart of signature enroll, and the one-at-a-time sibling of identity import. Unlike signature enroll, an unknown external_user_id creates the identity. Needs the opt-in IDENTITY_IMPORT grant (platform-enabled per tenant) and is charged one FACE_ENROLL use per enrolled face.

curl -X POST "$TF_BASE_URL/v3/tools/face-enroll/" \
  -H "x-api-key: $TF_API_KEY" -H "Content-Type: application/json" \
  -d '{"external_user_id":"user-123","image_base64":"<jpeg base64>","label":"account-opening","consent_reference":"Customer T&C v3"}'

• The photo must hold exactly one readable face (422 no_face_detected / multiple_faces); consent_reference is required.
• Re-sending the same photo for the same person returns the existing face with replayed: true (200, not charged again).
• Matches on other identities come back in duplicates (on_duplicate: report default, skip → 409, none).
• GET /v3/tools/face-enroll/?external_user_id=user-123 lists the person's enrolled faces; DELETE /v3/tools/face-enroll/{face_id}/ removes one. Neither is gated or charged.

Full reference: Standalone tools → Face enroll.

Document extract

Identity-document OCR — the same read as ID_VERIFICATION, run standalone. It uses the platform document-OCR service, so it works on any account regardless of the tenant's Lens config.

Gated by the DOCUMENT_OCR feature (403 feature_not_enabled when it is off, 402 insufficient_credits when the balance can't cover the rate) and charged one DOCUMENT_OCR use only when the read returned fields or generic text — 422 ocr_no_fields, 503 ocr_not_configured and other failed reads are not charged.

curl -X POST "$TF_BASE_URL/v3/tools/document-extract/" \
  -H "x-api-key: $TF_API_KEY" -H "Content-Type: application/json" \
  -d '{"image_base64":"<base64>","document_type":"passport"}'

const res = await fetch(`${process.env.TF_BASE_URL}/v3/tools/document-extract/`, {
  method: "POST",
  headers: {
    "x-api-key": process.env.TF_API_KEY!,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({ image_base64: imageB64, document_type: "passport" }),
});
const doc = await res.json();
console.log(doc.detected_type, doc.fields);

import requests

res = requests.post(
    f"{BASE_URL}/v3/tools/document-extract/",
    headers={"x-api-key": API_KEY},
    json={"image_base64": image_b64, "document_type": "passport"},
    timeout=30,
)
doc = res.json()
print(doc["detected_type"], doc["fields"])

{
  "fields": {
    "full_name": "AARAV SHARMA",
    "document_number": "PA1234567",
    "date_of_birth": "1990-04-12",
    "expiry_date": "2032-01-10",
    "nationality": "NP"
  },
  "translated_fields": {},
  "detected_type": "passport",
  "confidence": 0.97,
  "is_document_valid": true,
  "has_portrait": true
}

Template-less documents (e.g. disability cards) run a generic extraction — auto-detect fields plus best-effort local OCR text, flagged with generic_extraction: true and a full_text string. Aadhaar cards, which the classifiers can only call "national id" (or mistake for another card), and Indian PAN cards, which the local OCR reads as a PAN card without saying which country issued it, are recognised from OCR-text signals (the 4-4-4 Aadhaar number with its check digit, the UIDAI captions; the AAAAA9999A PAN number) and reported as aadhaar / pan_card with India as their country while India is enabled for your account. Auto-detected or sent as a hint, they are read the same way: by India's classifier first, and when it can't read them, by a best-effort read of the card's text (generic_extraction: true with its full_text). A document auto-detected from a country (or of a type) not enabled for your account is refused with 422 document_type_not_available rather than reported as something else — switching a country off removes its documents from the hint list and auto-detect immediately. 503 ocr_not_configured if the OCR service isn't available; 422 ocr_no_fields if nothing readable was found.

Registry lookup

KYB official-records check by number — the API twin of the console Registry Lookup tool, and the same registry validation a BUSINESS_DOCUMENT step runs on an uploaded company registration or VAT/PAN certificate. kind: "company" asks the Office of the Company Registrar by registration number; kind: "pan" asks the Inland Revenue Department (IRD) PAN search. Send the name you expect and it is fuzzy-matched against the registered English and Nepali names (legal suffixes, M/s / श्री and punctuation ignored).

Opt-in: gated on REGISTRY_VALIDATION (403 feature_not_enabled until the platform enables it for your account) and billed one REGISTRY_VALIDATION use per lookup the registry answered — matched, name_mismatch and not_found alike — at the same rate as the console tool and a workflow step's registry check. A lookup that couldn't be made is free, and so is a number that is only punctuation (.., /-/): there is nothing to look up, so it is refused as 400 invalid_number everywhere — and a workflow step that reads such a number off a certificate keeps the not_found verdict (held for review) without being charged.

The records are Nepal's, so the lookup follows the business-document tool's country rule: while Nepal is switched off for your account, registry-lookup and business-document both answer 422 document_type_not_available with the same body ({ detail, message, country: "NP" }) before anything runs — not charged.

curl -X POST "$TF_BASE_URL/v3/tools/registry-lookup/" \
  -H "x-api-key: $TF_API_KEY" -H "Content-Type: application/json" \
  -d '{"kind":"company","number":"000000/00/00","name":"Acme Technologies Pvt. Ltd."}'

const res = await fetch(`${process.env.TF_BASE_URL}/v3/tools/registry-lookup/`, {
  method: "POST",
  headers: {
    "x-api-key": process.env.TF_API_KEY!,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({ kind: "pan", number: "000000000", name: "Acme Technologies" }),
});
const lookup = await res.json();
console.log(lookup.status, lookup.record?.name_english);

import requests

res = requests.post(
    f"{BASE_URL}/v3/tools/registry-lookup/",
    headers={"x-api-key": API_KEY},
    json={"kind": "pan", "number": "000000000", "name": "Acme Technologies"},
    timeout=60,
)
lookup = res.json()
print(lookup["status"], lookup["record"] and lookup["record"]["name_english"])

{
  "kind": "company",
  "source": "company_registrar",
  "status": "matched",
  "found": true,
  "number": "000000/00/00",
  "number_used": "000000/00/00",
  "name_check": { "similarity": 1.0, "threshold": 0.8, "matched": true },
  "record": {
    "number": "000000",
    "name_english": "Acme Technologies",
    "name_nepali": "एक्मे टेक्नोलोजिज",
    "registration_date_bs": "2081-08-27",
    "address": "Lalitpur Metropolitan City-1, Lalitpur",
    "company_type": "All Nepali Ownership",
    "office": null,
    "registrations": null,
    "tax_clearance": null
  }
}

400 invalid_number when the number is only punctuation or outside the registry's format (with the reason in message), 422 document_type_not_available while Nepal is switched off for your account, 502 registry_unavailable when the registry or the government website behind it didn't answer, 503 registry_not_configured when the deployment has no registry configured — none of them charged. Full reference: Standalone tools → Registry lookup.

Liveness

Three endpoints, one engine: the same models, verdict rules and pass floors as the Liveness module with its default configuration. Unlike a session they keep nothing — the selfie, clip and frames are scored in memory and discarded; the only stored row is an active challenge (its colour/action sequence and expiry), which anti-replay needs and which is deleted a day after it expires.

If you'd rather not build a capture UI at all, run liveness as a one-module hosted session instead — see Liveness via API for when to pick which.

Gate and billing. Each call needs the LIVENESS module and the method key (PASSIVE, PASSIVE_VIDEO, FLASHING, 3D_ACTION, GESTURE) on your plan; a 403 feature_not_enabled lists every key that's off. This is stricter than a session, which never drops liveness: a session whose method is switched off quietly runs PASSIVE instead, even when PASSIVE itself is off. The tools never substitute a method — a switched-off key, PASSIVE included, is a 403. A call is billed exactly like one liveness run in a session: under the method key when that method has its own rate, otherwise under LIVENESS. Only a returned verdict (approved, declined or review) is billed — capture failures (422), an unavailable engine (503), input errors and challenge issuing are free.

Response. Every verdict has the same shape:

{ "method": "PASSIVE", "status": "approved", "passed": true, "score": 91.37 }

Model names, raw anti-spoof probabilities and thresholds are never returned.

Passive liveness

curl -X POST "$TF_BASE_URL/v3/tools/liveness/" \
  -H "x-api-key: $TF_API_KEY" -H "Content-Type: application/json" \
  -d '{"image_base64":"<jpg/png base64>","check_sunglasses":true}'

const res = await fetch(`${process.env.TF_BASE_URL}/v3/tools/liveness/`, {
  method: "POST",
  headers: { "x-api-key": process.env.TF_API_KEY!, "Content-Type": "application/json" },
  // Add video_base64 (MP4 or WebM, ≤ 20 MB) to run PASSIVE_VIDEO.
  body: JSON.stringify({ image_base64: selfieB64 }),
});
const out = await res.json();
if (res.status === 422) console.log("retake:", out.reason ?? out.detail);
else console.log(out.status, out.score);

import requests

res = requests.post(
    f"{BASE_URL}/v3/tools/liveness/",
    headers={"x-api-key": API_KEY},
    json={"image_base64": selfie_b64, "video_base64": clip_b64},  # clip optional
    timeout=60,
)
print(res.status_code, res.json())

{ "method": "PASSIVE_VIDEO", "status": "declined", "passed": false, "score": 18.2,
  "reason": "video_liveness_failed", "video_verified": true }

With a clip, the verdict is the clip's — but only for the person in the still. A few frames from the clip are face-matched against image_base64; when the clip shows someone else (or no readable face at all) the result is declined with still_clip_mismatch, so an approved PASSIVE_VIDEO still is safe to hand to POST /v3/tools/face-verify/.

Errors: 422 quality_rejected with a reason you can show as a retake hint (too_blurry, face_too_small, poor_lighting, sunglasses_detected, face_occluded, face_not_frontal, low_quality, multiple_faces); 422 no_face_detected; 413 video_too_large; 415 unsupported_video_type; 503 liveness_engine_unavailable. None are billed.

Active liveness: challenge

Mint a challenge, run it in your own capture UI, then verify. A challenge is single-use, expires after 2 minutes (expires_at) and belongs to your tenant only.

curl -X POST "$TF_BASE_URL/v3/tools/liveness/challenge/" \
  -H "x-api-key: $TF_API_KEY" -H "Content-Type: application/json" \
  -d '{"method":"FLASHING"}'

const ch = await fetch(`${process.env.TF_BASE_URL}/v3/tools/liveness/challenge/`, {
  method: "POST",
  headers: { "x-api-key": process.env.TF_API_KEY!, "Content-Type": "application/json" },
  body: JSON.stringify({ method: "3D_ACTION" }),
}).then((r) => r.json());
// ch.actions, ch.prompts, ch.window_ms → drive your capture screen

ch = requests.post(f"{BASE_URL}/v3/tools/liveness/challenge/",
                   headers={"x-api-key": API_KEY}, json={"method": "GESTURE"},
                   timeout=15).json()

The 201 body carries the same fields the hosted flow's capture screens use:

{ "challenge_id": "0b6a2c1e-…", "method": "FLASHING",
  "sequence": ["R", "W", "G", "B", "R", "G", "B"],
  "frame_ms": 450, "lead_ms": 250, "n": 7, "expires_at": "2026-09-13T08:02:00Z" }

{ "challenge_id": "…", "method": "3D_ACTION", "actions": ["turn_left", "look_up", "smile"],
  "prompts": {"turn_left": "Turn your head to the left", "look_up": "Tilt your head up", "smile": "Smile"},
  "window_ms": 4000, "mirror": true, "expires_at": "…" }

{ "challenge_id": "…", "method": "GESTURE", "gestures": ["palm", "like", "peace"],
  "prompts": {"palm": "Show your open palm", "like": "Give a thumbs up", "peace": "Show a peace sign (two fingers)"},
  "required": 2, "window_ms": 4000, "expires_at": "…" }

Capture contract (what the hosted UI does — the scorers are tuned to it):

• FLASHING — front camera, face filling the frame, screen brightness up. Fill the screen black for ~500 ms, then for each colour in sequence (R #ff0000, G #00ff00, B #0000ff, W #ffffff): paint the whole screen that colour, wait lead_ms (so the camera exposes the new light), grab one frame and record its timestamp, then hold until frame_ms has elapsed since the colour appeared. You end with exactly n frames. emitted_order is the list of colours you actually painted, in order (normally equal to sequence; any difference declines as sequence_altered). frame_timestamps are the capture times in milliseconds from any monotonic clock (e.g. performance.now()), one per frame and strictly increasing — out-of-order or mismatched timestamps decline as timing_anomaly.
• 3D_ACTION — for each action: show its prompt (mirror the preview when mirror is true), give ~700 ms to start moving, then grab frames at ~10 fps for window_ms. Label every frame with the action it was captured under in frame_actions.
• GESTURE — same as 3D_ACTION with prompts for hand gestures (~900 ms lead, ~9 fps for window_ms), labelled in frame_gestures. At least required gestures must be recognised, with the face in view while each is performed — hand-only frames decline as no_face_detected.

Active liveness: verify

Accepts multipart/form-data — repeated frames files, metadata arrays as JSON strings, exactly what the hosted flow sends — or JSON with frames_base64. Frames are JPEG/PNG, at most 180 frames, 2 MB each and 32 MB total.

# FLASHING, multipart
curl -X POST "$TF_BASE_URL/v3/tools/liveness/verify/" \
  -H "x-api-key: $TF_API_KEY" \
  -F challenge_id=0b6a2c1e-… \
  -F [email protected] -F [email protected] -F [email protected] -F [email protected] \
  -F [email protected] -F [email protected] -F [email protected] \
  -F 'emitted_order=["R","W","G","B","R","G","B"]' \
  -F 'frame_timestamps=[812.4,1263.0,1714.8,2166.1,2617.5,3068.9,3520.2]'

// 3D_ACTION, multipart (browser or Node 18+)
const fd = new FormData();
frames.forEach((blob, i) => fd.append("frames", blob, `f${i}.jpg`));
fd.append("challenge_id", ch.challenge_id);
fd.append("frame_actions", JSON.stringify(frameActions)); // one label per frame
const out = await fetch(`${process.env.TF_BASE_URL}/v3/tools/liveness/verify/`, {
  method: "POST",
  headers: { "x-api-key": process.env.TF_API_KEY! },
  body: fd,
}).then((r) => r.json());
console.log(out.status, out.per_action_pass);

# GESTURE, JSON
res = requests.post(
    f"{BASE_URL}/v3/tools/liveness/verify/",
    headers={"x-api-key": API_KEY},
    json={
        "challenge_id": ch["challenge_id"],
        "frames_base64": frames_b64,          # capture order
        "frame_gestures": frame_labels,       # same length as frames_base64
    },
    timeout=120,
)
print(res.status_code, res.json())

{ "method": "GESTURE", "status": "declined", "passed": false, "score": 33.3,
  "reason": "gesture_not_performed",
  "per_gesture_pass": { "palm": true, "like": false, "peace": false } }

Single use. Request validation runs before the challenge is spent, so a 400/413/415 lets you fix the request and retry with the same challenge_id. Once it gets past validation the challenge is claimed atomically: a second verify — even a concurrent one — gets 409 replayed and is neither scored nor billed. A verdict or a 503 spends the challenge; mint a new one to retry.

Error codes

FAQ

Related