Reference · built on requestConnectorPayments, billing & fraud

Sift

User and transaction events, abuse scores, Decisions, and Decision webhooks through the Sift Events, Score, and Decisions APIs.

Request accessPricing ↗

About

Sift scores users and activity for payment abuse, account takeover, promotion abuse, content abuse, and account abuse. You send reserved events such as $create_order, $transaction, $login, and $chargeback to the Events API, ask for a score in the same call or from the Score API, and apply Decisions to users, orders, sessions, or content. Workflows in the Sift Console can block, accept, or route an entity to a Review Queue, and a Decision webhook fires when a Decision is applied.

Through Fibric, an operator reads the score and the latest Decision for an order or user and proposes what to do next: apply a Decision, send the $chargeback event when a dispute arrives, or hold a shipment. You approve, and the record of the call stays with the order.

This is a reference listing. It documents what Fibric would read from Sift and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Scores returned with an event when return_score is set, per abuse type: payment_abuse, promotion_abuse, content_abuse, account_abuse, account_takeover, or legacy
  • The latest Decision for a user, order, session, or content entity from GET /v3/accounts/{accountId}/users/{userId}/decisions and its order, session, and content variants
  • Decision webhooks, version 1.0, with entity.type, entity.id, decision.id, and time, signed in the X-Sift-Science-Signature header
  • Workflow run status when return_workflow_status is set, including whether a Decision was applied by the Workflow
  • Score percentiles when the request adds fields=score_percentiles
  • Available Decisions per entity_type and abuse type from GET /v3/accounts/{account_id}/decisions

Proposed actions

  • Target capability: propose sending a reserved event to POST https://api.sift.com/v205/events, such as $create_order, $update_order, $order_status, or $transaction, keyed by $user_id
  • Target capability: propose recording a chargeback with the $chargeback event, setting $chargeback_state ($received, $accepted, $disputed, $won, $lost) and $chargeback_reason
  • Target capability: propose applying a Decision through POST /v3/accounts/{accountId}/users/{userId}/decisions or the order, session, and content paths, with decision_id, source, analyst, and description
  • Target capability: propose a fresh score through POST https://api.sift.com/v205/users/{UserId}/score for the abuse types you name

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Pause a high-score order before fulfillment

    The $create_order event returns a payment_abuse score. The operator compares it with the Workflow's outcome, proposes a shipping hold, and shows you the score percentile before you decide.

    With Order Risk

  • Record the chargeback where the model learns from it

    When a dispute arrives from your processor, the operator proposes a $chargeback event with $chargeback_state $received and the mapped $chargeback_reason, then updates it to $won or $lost when the case closes.

    With Chargeback Evidence

  • Apply a Decision after a support review

    An agent concludes a refund request is abuse. The operator proposes the matching Decision with source MANUAL_REVIEW and the agent's email as analyst, for your approval.

    With Refund Policy, Concession Review

Requirements

  • A Sift account with its account ID and separate sandbox and production REST API keys from the Console's API Keys section
  • Decisions created in the Console's Decisions section before the API can apply them
  • A Webhook Signature Key, SHA-256 preferred over SHA-1, when Decision webhooks are enabled
  • Consistent, case-sensitive $user_id values across events so chargebacks match the right user
Authentication
A Sift REST API key, sent as $api_key in the JSON body or as HTTP Basic with the key as the username, with a Webhook Signature Key from the Console for verifying Decision webhooks.

Limits

  • Events API traffic is limited to 500 requests per second per account and 3 per second per $user_id; with synchronous scores, 27 and 1.
  • The Decisions API allows 40 requests per second and the Score API 9.
  • Status 64 means the user has no computed score yet; status 60 means the request was rate limited.
  • Amounts are sent in micros, where 1 cent equals 10,000 micros, and a currency without cents uses 1,000,000 micros per unit.

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Sift ↗

Questions and answers

Does Sift return a score synchronously?
Yes. Add return_score or return_workflow_status to the Events API call and the response includes a score object per abuse type named in abuse_types. Add fields=score_percentiles for percentiles. These calls have the lower per-second limits.
When does a Decision webhook fire?
Whenever a Decision is applied, by a person or automatically by a Workflow, to a Decision that has a webhook configured in the Console. The body carries entity, decision.id, and time. Verify X-Sift-Science-Signature with your Webhook Signature Key.
Which source values can a Decision carry?
MANUAL_REVIEW, AUTOMATED_RULE, and CHARGEBACK are the documented sources. The optional analyst field holds the reviewer's email and description holds free text about the reason.
Ask about Sift

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with Sift through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy