Quick start

Rupt works the same on every platform: run an evaluation when the user takes an action, then confirm it on your server before you honor it. Here's the flow:

The integrity check is where your server confirms the evaluation matches what your client app sent and hasn't been tampered with.

1. Install the Rupt SDK

npm install @ruptjs/client

2. Run an evaluation (client-side)

Call evaluate() at the moment the user takes the action (e.g. right after they submit the login, sign up, or checkout).

import Rupt from "@ruptjs/client";

const rupt = new Rupt({ clientId: "your_client_id" });

// Call rupt.evaluate.login / .signup / .access for the action you're protecting.
const response = await rupt.evaluate.login({
  user: "USER_ID",
  email: "EMAIL",
  phone: "PHONE",
  metadata: { key: "value" },
});

The response includes the evaluation_id that you need to send to your server in step 3.

3. Confirm the evaluation (server-side)

This step takes place on your server. Your server should take the evaluation_id from the client and get that evaluation details from Rupt.

import RuptAPI from "@rupt/api";

const rupt = new RuptAPI("API_SECRET");
const evaluation = await rupt.evaluation.get(evaluation_id);

/** Alternatively: curl https://api.rupt.dev/v3/evaluations/$EVALUATION_ID \ -H "Authorization: Bearer $API_SECRET" **/

The response includes the verdict, the action, the user details Rupt received, the policy that matched, the risks detected, and the challenge if one was issued, and more:

{
  "id": "...",
  "action": "login",
  "verdict": "allow",
  "user": {
    "rupt_id": "...",
    "id": "USER_ID", // The user ID you provided to Rupt
    "email": "EMAIL", // The email you provided to Rupt
    "phone": "PHONE" // The phone you provided to Rupt
  },
  "metadata": { "key": "value" }, // The metadata you provided to Rupt
  "policy": { "id": "...", "name": "...", "action": { "type": "allow" } }, // The policy that matched
  "challenge": null, // The challenge details if one was issued
  "redirect": null, // The redirect URL if one was issued
  "risk_summary": [{ "category": "ato", "severity": "low" }], // The risks detected
  "createdAt": "...",
  "updatedAt": "..."
}

Confirm that the evaluation matches the action you expected, the user you expected, and the metadata you expected. Treat any mismatch as a bad actor and block the action.

4. Handle challenges

Out of the box you have no policies, so every evaluation comes back allow and no challenge fires. That's expected; the steps above give you the plumbing and all the data you need to start writing policies that challenge, deny, or gate an action.

When a policy does issue a challenge, the evaluation comes back with a redirect. Sending the user through the hosted challenge and confirming they passed is a short round trip — the Challenge flow walks through it end to end.

Start with the two foundations; every other use case builds on them:

• Signup protection — at signup the user is new and has no ID yet, so you store a little state to bind the pending signup to its challenge.
• Login protection — at login you don't store anything; you just hold off issuing the session until the challenge completes.

Next steps

• Concepts — what evaluations, signals, checks, risks, verdicts, policies, and challenges actually mean.
• Guides — recommendations on specific fraud-prevention scenarios.
• Proxy setup — route Rupt traffic through your own domain to bypass adblockers and JS-domain blocking.