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 "@ruptjs/api";

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

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.

Policies that issue a deny verdict are easy; you should refuse the action immediately. Challenges are a little more

When a policy does issue a challenge verdict, the evaluation comes back with a redirect. You should send the user to that redirect URL. It contains a hosted challenge. When the user completes the challenge, you should confirm it on your server before honoring the action. 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.