Scorift
Status Back
Developers

Scorift API — real-time fraud decisions in one request

Scorift is a Fraud Detection API-as-a-Service. You send a single HTTPS request containing a transaction, login, payout, or account event, and our platform returns a machine-readable decision — approve, flag, or reject — in under 50 milliseconds, with a numeric risk score and a full explanation of why that decision was made.

What you send
POST /v1/score
event, amount, user_id, device_id, ip, email, geo, metadata
What we evaluate
Your rules plus Scorift's adaptive risk context across device, identity, geo, and velocity
What you receive
score, action, risk_level, signals, rules, trace_id

What this API does

Scorift acts as a real-time risk gatekeeper for any digital transaction or account event. Instead of building and maintaining your own fraud stack — rule tooling, risk scoring, audit pipelines, and case-review workflows — you route events through our API and receive a decision your backend can act on immediately.

A typical integration looks like this:

  1. Capture the event — your app collects a checkout, login, transfer, payout, or signup attempt.
  2. Send one POST /v1/score request — pass the event type, value, and any available identifiers (user, device, IP, email, location, payment method).
  3. Read the decision — use the returned action to approve automatically, route to a manual review queue, or reject the transaction.
  4. Audit and refine — every decision is traceable by trace_id, reviewable in the dashboard, and adjustable through rules or webhooks without redeploying your app.

How the decision is made

Every request is evaluated in three explainable stages:

Stage 1
Deterministic rules

Business policies you control: allow-lists, deny-lists, velocity windows, geo restrictions, and amount thresholds. These always execute first.

Stage 2
Adaptive risk scoring

Scorift scores the event against behavioural risk context spanning device, identity, network, and transaction patterns. Returns a 0–1 risk score.

Stage 3
Override gates

Manual reviews, case decisions, and admin overrides can promote or demote the final action before it is returned to your app.

Evaluation is repeatable for the same request, versioned per tenant, and audited end-to-end. The response tells you which of your rules fired and which risk signals contributed, so the decision is never a black box.

The response contract

{
  "score":      0.87,        // 0.00 – 1.00 risk score
  "risk_level": "high",      // low | medium | high
  "action":     "reject",    // approve | flag | reject
  "signals":    ["velocity", "sim_swap", "geo_mismatch"],
  "rules":      ["r_high_value_new_device"],
  "trace_id":   "trc_01HBX7YQ",
  "latency_ms": 42
}

action is the value your application should branch on. approve means the event can proceed; flag sends it to a review queue; reject blocks it immediately. Persist trace_id — it is the join key for webhooks, case review, audit logs, and billing.

Common use cases

  • Payment fraud — approve, flag, or reject card, wallet, instant-transfer, and checkout events at the moment of authorization.
  • Account security — detect account takeover, credential stuffing, and suspicious device or location changes on login and password reset.
  • Payout and seller risk — hold marketplace payouts, gig-worker withdrawals, or creator payouts when new devices or high-risk signals appear.
  • Onboarding — score new signups, KYC retries, and document submissions for synthetic identity or mule-account risk.

Base URLs

Production   https://api.scorift.com/v1
Sandbox      https://sandbox.scorift.com/v1

All endpoints require an Authorization: Bearer sk_… header. Use sk_test_… against the sandbox and sk_live_… against production. The sandbox is functionally identical to production but produces no billing events or downstream side effects. See Authentication for the full policy.

Get started

  1. Create a Scorift account and generate a sandbox API key.
  2. Send your first POST /v1/score request — see the Quickstart.
  3. Author your first rule in the dashboard or via POST /v1/rules.
  4. Wire up a signed webhook receiver for async events.