One HTTPS call in. A scored, explained verdict out: action, reasons, evidence and confidence. EU-built, PII-free, fail-closed auth, pay per call.
No raw PII, ever. Send opaque signal ids and context. Get back an action, a score and the reason behind it, in one round trip.
"degraded": true.# POST a signal bundle, get one explained decision back curl -X POST https://vilkax.com/api/partner/v1/decide \ -H "Authorization: Bearer $VILKAX_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "signals": [ { "id": "process.remote_access_tool", "value": 0.9 }, { "id": "text.urgency_pressure", "value": 0.8 }, { "id": "transfer.outbound_initiated", "value": 1.0 } ], "context": { "action_kind": "transfer" } }' → { "action": "review", "score": 84, "why": "Remote-access tool + urgency during a transfer." }
Get a key, make one call, act on the verdict. Every example targets a real, live endpoint.
vlx_live_… and a tier. The plaintext is shown once; we store only its SHA-256 hash.Authorization: Bearer on every request. Each endpoint needs a scope the key carries.usage is free.Real, deployed routes on https://vilkax.com. Fields add, never break.
"deep": true to run the semantic rung over text - the same paraphrase-invariant layer our own apps use, for scams no pattern covers.decide3 · 5 deepsignals:* grant the family. Under-scoped keys fail closed."deep": true adds the semantic rung, which catches a scam phrased in words our pattern corpus has no literal for. The response carries deep_applied, and you are billed for the engine that answered, not the one you asked for."degraded": true. Never a false all-clear.One call returns a 0 to 100 hazard score and an advisory verdict. If an order disputes, the representment evidence packet is ready to file with your acquirer.
Lookups bill 1 unit, deep calls 3, usage is free. No seat fees.
Every product is a scope on your key, metered per successful call, rate limited, audited and documented in the OpenAPI 3.1 spec. Call GET /api/partner/v1/capabilities to see exactly what your key can use. Commercial terms: contact us.
| Domain | Products (POST/GET /api/partner/v1/...) |
|---|---|
| Decisioning | decide · explain · policy · policy/simulate · intervene · anticipate (alias risk/sequence) · review · evaluate · outcome |
| Fraud and scams | message/scan · phone/risk · qr/risk |
| Payments | payee/risk (IBAN, Pix, UPI, mobile money, crypto) · transaction/risk · crypto/screen |
| Cyber | url/risk · file/risk · email/auth · domain/security · ip/risk · login/risk · endpoint/posture · prompt/injection |
| Identity and abuse | signup/risk · bot/risk |
| Physical safety | incident/nearby (country level, k-anonymised) · travel/risk. No individual tracking, ever. |
| Threat intelligence | intel/feed?scope=fraud|cyber|physical|brand as JSON pages, NDJSON or STIX 2.1 |
| Brand protection | brand/monitors · brand/monitors/{id}/scan · brand/alerts |
| Platform | capabilities · webhooks · webhooks/{id}/test · webhooks/deliveries |
Every decision product answers in the same shape: decision.action (allow, warn, step_up, hold, block or human_review), a calibrated confidence, a 0 to 100 risk_score, the threat taxonomy ids, structured evidence, plain-language explain text and a decision_ref. Send the decision_ref back to POST /api/partner/v1/outcome when you learn what happened; that feedback is how decisions improve.
curl -s https://vilkax.com/api/partner/v1/message/scan \
-H "Authorization: Bearer vlx_live_..." -H "Idempotency-Key: 7c2e..." \
-H "content-type: application/json" \
-d '{"text":"Your account is locked, move your savings to a safe account","channel":"sms"}'
{ "ok": true, "request_id": "req_...", "product": "message.scan",
"decision_ref": "pd_...",
"decision": { "action": "hold", "confidence": 0.86, "risk_score": 72,
"decision_type": "scam_social_engineering",
"taxonomy": { "taxonomy_version": "...", "domain": "fraud", "type": "...", "family": "..." },
"evidence": [ { "type": "signal", "code": "text.safe_account_transfer", "detail": "..." } ],
"human_review_required": false, "policy_version": 3 },
"explain": { "summary": "...", "next_step": "..." },
"billed_units": 1 }
High-stakes categories (child exploitation, grooming, trafficking, abuse) always return human_review. No partner policy can turn that into an automated block or an allow, and the API never makes a statement about a person: it assesses behaviour and patterns.
Decisions may draw on every signal Vilkax is licensed to use, including licensed third-party sources, because you are buying the verdict, not the data. The intelligence feed is different: it ships only rows Vilkax is allowed to redistribute, only confirmed indicators, hash-keyed with defanged previews. Personal identifiers such as phone numbers, email addresses and bank accounts are matched on query as hashes and are never exported in bulk. Vilkax sells verdicts and threat intelligence, never user personal data, profiles, messages or contacts.
vlx_live_ keys run live engines. vlx_test_ keys run a sandbox that returns deterministic fixtures in the same contract: a value containing sandbox-block returns block, sandbox-review returns hold, and a person subject returns human_review. Sandbox calls are never billed. Responses carry x-request-id, x-vilkax-api-version, x-billed-units and quota headers; a POST accepts Idempotency-Key and replays the stored answer for 24 hours. Errors are {"ok":false,"error":"<code>","detail":"...","request_id":"..."} with stable codes such as insufficient_scope, tier_required, quota_exceeded, product_rate_limited and partner_suspended. Retired products announce themselves with Deprecation and Sunset headers before they leave /v1.
Subscribe an HTTPS endpoint to campaign.detected, brand.lookalike, indicator.confirmed, review.created, review.updated and decision.human_review. Each delivery is signed: x-vilkax-signature: t=<unix>,v1=<hex HMAC-SHA256> over t + "." + rawBody with your endpoint secret, which is shown once. Failed deliveries are retried with backoff and visible in webhooks/deliveries.
Request one from the contact form. We issue your vlx_live_ key and tier; the plaintext is shown exactly once. A self-serve portal is on the way.
No. Decisioning endpoints take opaque signal ids only; raw PII is rejected with pii_in_features. Lookup values (email, phone, domain, IP, wallet) are hashed server-side.
Yes, via the guard:* scope family. POST to /api/business/v1/guard/evaluate with a hashed order (no raw PII) and get back a 0 to 100 hazard score and an advisory verdict. If that order later disputes, POST the chargeback to /guard/dispute and receive a representment evidence packet, reason-code classification, evidence mapping and dispute strategy, ready to file with your acquirer.
They score isolated purchase signals within their merchant network. Guard additionally draws from the Vilkax anti-scam intelligence layer, the consumer-side behaviour patterns and entity-graph signals that protect people. An inbound counterparty can be scored against known social-engineering victim and mule patterns before the transaction posts. The advisory score is native to the API call, not a separate integration.
Start free, wire one call, and decide with evidence from day one. We issue your vlx_live_ key and tier.
Not building yet? Get on the developer early-access list and we'll email you the moment the Protect API opens.