Skip to main content
POST
Evaluate a flow
Eval is in beta. The request and response shapes may still change, and flows and recipes are configured by Prelude on your behalf for now — there is no self-serve authoring surface yet. Talk to us before you build against it.
Call Eval at any moment you want to guard — signup, checkout, password reset, a payout request. Set flow_id to the flow configured for that moment, and target.type to phone_number or email_address with the corresponding value. A flow selects which recipes run. Each recipe scores its rules against a threshold and returns its own verdict; the evaluation answers with the most severe verdict and action across all of them. Eval is scoring-only and advisory. It does not update long-lived abuse counters by itself, and action is a recommendation — enforcement is yours.

Eval or Predict?

Both score an identifier. They differ in what they return and what you control. Use Predict when you want an answer. Use Eval when you want to see the reasoning, tune it, or add conditions of your own.

Reading the response

Start at recipes[].verdict and work down. A recipe flags when its score reaches its threshold, unless a preempting rule settled it first — that case sets determined_by, which is the only thing accounting for a recipe that reports a score under its threshold and flags anyway. partial_evidence means at least one rule could not run, so the score rests on less than the whole recipe. Each such rule reports outcome: NOT_EVALUATED with a blocked_by naming what it waited on. This is not a quieter NOT_TRIGGERED — the rule contributed nothing in either direction, so a PASS carrying partial_evidence is weaker evidence than a PASS without it. The usual cause is a signal that never arrived. Passing dispatch_id from the front-end SDK fills in most of what rules read; without it, any rule reading a device or network signal reports NOT_EVALUATED.

Rules you did not write

Your recipes can include Prelude-managed rules alongside your own. A managed rule returns its rule_id, weight and outcome, but not its name, and reports blocked_by: "missing_data" rather than naming the signal it needed — its condition is not disclosed. The identifier is always returned, so a rule whose condition you cannot see is still one you can reweight, switch off, or ask us about.

Attributes

Rules can read values only your application knows — a plan tier, an account’s age, a cart total. Recipes declare which ones they use; you supply them in attributes, keyed without the attr. prefix a rule expression uses. An attribute a recipe declares and your request omits is treated as missing evidence, not an empty value: rules reading it report NOT_EVALUATED rather than being scored as though the condition were false. A key no recipe in the flow declares is ignored rather than rejected, so one payload can serve flows that read different attributes.

Authorizations

Authorization
string
header
required

Bearer authentication header of the form Bearer <token>, where <token> is your auth token.

Body

application/json
flow_id
string
required

The flow to evaluate. A flow names the moment you are guarding and selects the recipes that run.

Example:

"flo_01jc0t6fwwfgfsq1md24mhyztj"

target
object
required

The identifier to score — a phone number or email address.

signals
object

The signals used for anti-fraud. For more details, refer to Signals.

dispatch_id
string

The identifier of the dispatch that came from the front-end SDK. Signals it carries fill in anything the request did not state; the request wins where both supply a value.

Required string length: 36
Example:

"123e4567-e89b-12d3-a456-426614174000"

attributes
object

Values for the attributes the flow's recipes declare, keyed without the attr. namespace a rule uses to reference them.

An attribute a recipe declares and this request omits is treated as missing evidence, not as an empty value: the rules reading it report NOT_EVALUATED rather than being scored as though the condition were false. A key no recipe in the flow declares is ignored rather than rejected, so one payload can serve flows that read different attributes.

Example:

Response

OK

id
string
required

The evaluation identifier.

Example:

"evl_01jc0t6fwwfgfsq1md24mhyztj"

verdict
enum<string>
required

The evaluation-level verdict, being the most severe verdict across the recipes that ran.

  • PASS - No recipe flagged.
  • FLAG - At least one recipe flagged.
Available options:
PASS,
FLAG
action
enum<string>
required

What the evaluation suggests you do, being the most severe action across the recipes that ran. Advisory: enforcement is yours.

  • ALLOW - Let the request through.
  • BLOCK - Refuse the request.
  • CHALLENGE - Let the request through behind an additional check.
Available options:
ALLOW,
BLOCK,
CHALLENGE
recipes
object[]
required

One result per recipe that ran. A recipe the flow names but that is not in service is absent rather than reported as having passed.