Ellipse Gradient for Header

Sift Integration Guide

Integrate Sift with enterprise systems through REST APIs, selected webhook-style notifications, and Martini workflows for risk evaluation and decision orchestration.

Sift integration options at a glance

Sift’s primary integration model is REST APIs for submitting behavioral and transactional Events, sending Orders and payment activity, and retrieving Users, Scores, and Decisions. Sift also supports webhook-style outbound notifications for selected decision or risk use cases, although coverage is not universal across all objects. Batch-style event submission may be available for applicable API versions and endpoints. Martini can consume Sift REST APIs, expose an API for supported callbacks, transform source payloads, and orchestrate synchronous or scheduled workflows. API-key credentials can be stored in Martini Secrets Management, while retries, throttling, validation, partial batch failures, and downstream decision routing are handled in workflow logic.

Integration pointSupported by Sift?Common use casesHow Martini supports it
REST APIsYesSubmit Users, Events, Orders, and payment-related activity; retrieve Scores, Decisions, and risk information.Martini can consume Sift REST endpoints, centralize API version and headers, map payloads, and orchestrate downstream actions.
Webhooks / outbound callbacksLimitedReceive selected decision or risk-related notifications from Sift where enabled by the applicable product and configuration.Martini can expose a REST API to receive callbacks, validate and normalize payloads, and route them to downstream workflows.
Bulk / batch event submissionLimitedSubmit groups of Events when the applicable Sift API version and endpoint support batch-style processing.Martini can build controlled batches, track item-level acceptance and rejection, retry eligible items, and preserve failures.
AuthenticationYesAuthenticate API requests with Sift API keys and the headers required by the applicable API version.Martini can reference API keys from Secrets Management and apply HTTPS request authentication without embedding credentials in workflows.
Scheduled synchronizationYesRun historical loads, reconciliation, or periodic retrieval workflows for supported Sift resources and source data.Martini can trigger scheduled workflows, checkpoint progress, paginate collection reads, and control throughput.
Event-driven workflowsYesForward login, account, payment, order, chargeback-related, or other supported behavioral activity to Sift as it occurs.Martini can receive source events, transform them into Sift payloads, submit them, and route risk outcomes using business rules.
File / attachment APIsNot confirmedNo general-purpose Sift file or attachment API was confirmed for the primary risk and event integration model.Martini should use documented Sift APIs or confirmed exports instead of assuming file exchange support.
Database / analytics accessNot confirmedNo direct database access mechanism was confirmed for Sift.Martini can integrate through Sift APIs and supported enterprise data endpoints rather than connecting to an underlying Sift database.

How Sift exposes data and business events

Sift REST APIs

REST APIs are Sift’s principal integration mechanism for submitting Users, Events, Orders, and payment activity and for retrieving Scores, Decisions, and risk information. API paths and payloads are versioned, so the selected version and common headers should be managed consistently.

Martini implementation pattern

Martini implementation pattern: a workflow receives or retrieves source data, validates the required Sift event structure, maps fields into the selected API version, calls Sift with an API key from Secrets Management, and routes the response according to business rules.

Implementation sequence

Receive or retrieve the source activity
Validate required event and identity fields
Map the source payload to the Sift API model
Submit the request with the configured API key
Interpret the Score or Decision response
Write the outcome and correlation identifiers

Sift webhook-style callbacks

Sift supports webhook-style outbound notifications for selected decision or risk-related use cases. These notifications are product- and event-specific and should not be treated as a universal stream for every Sift object.

Martini implementation pattern

Martini implementation pattern: expose a controlled REST API, validate the callback according to the enabled Sift notification configuration, normalize the payload, and route the associated User, Order, Decision, or risk result to downstream systems.

Implementation sequence

Receive the Sift callback
Validate the request and notification context
Normalize the callback payload
Identify the related User or Order
Apply downstream routing rules
Record processing status and duplicate safeguards

Sift batch event submission

Sift may support batch-style Event submission for applicable API versions and endpoints. Batch processing requires attention to maximum counts, partial acceptance, item-level validation errors, replay, deduplication, and rate limits.

Martini implementation pattern

Martini implementation pattern: a scheduled or source-triggered workflow collects eligible activity, partitions it into controlled batches, submits each batch, separates accepted and rejected items, and retries only eligible failures.

Implementation sequence

Read the next source checkpoint
Validate and partition Events into batches
Submit the batch to the applicable Sift endpoint
Record accepted and rejected items separately
Retry eligible transient failures with backoff
Advance the checkpoint after durable processing

Common Sift integration patterns

Pattern 1: Evaluate transactions before order fulfillment

When to use this pattern

Use this pattern when a commerce or payment process needs a Sift risk outcome before approving, holding, or rejecting an Order. The workflow should distinguish a business Decision such as review or block from transport, validation, or authentication failures.

Integration direction
Commerce or payment application
Martini
Sift
Order management system
Example Mapping
Sift FieldCanonical FieldTarget Field
user_idcustomer.idSift user identifier
order_idorder.idSift order identifier
amountorder.totalSift transaction amount
payment_methodpayment.methodSift payment context
Martini implementation pattern

Martini receives the order or payment event, validates customer and transaction data, transforms it into the Sift Event or Order model, submits it through the REST API, and maps the response to approved, review-required, or blocked states. Transient failures are retried without treating them as risk Decisions, while correlation identifiers are persisted for reconciliation.

Martini capabilities used
  • workflows
  • API consumption
  • data mapping
  • business rules
  • error handling
  • secrets management

Pattern 2: Monitor account takeover activity

When to use this pattern

Use this pattern for login, password-reset, account-change, or authentication activity that should contribute to Sift risk evaluation and may trigger step-up verification, account locking, or a security case.

Integration direction
Application authentication service
Martini
Sift
Security or case-management system
Example Mapping
Sift FieldCanonical FieldTarget Field
event_namesecurity.activity.typeSift Event name
user_idcustomer.idSift user identifier
iprequest.network.ipSift network context
device_iddevice.idSift device context
Martini implementation pattern

Martini consumes application activity, applies event-name and data-quality rules, submits relevant Events to Sift, and routes the returned Score or Decision to account-security processes. Invalid payloads are isolated for review, while rate-limit and service failures follow controlled retry paths.

Martini capabilities used
  • event-driven workflows
  • API consumption
  • mapping and transformation
  • validation
  • conditional routing
  • error handling

Pattern 3: Process Sift decision callbacks

When to use this pattern

Use this pattern when selected Sift decision or risk notifications should update order operations, CRM activity, or a fraud-review process without repeatedly polling for every outcome.

Integration direction
Sift
Martini
ServiceNow
Example Mapping
Sift FieldCanonical FieldTarget Field
decisionrisk.outcomecase.status
user_idcustomer.idcase.customer_reference
order_idorder.idcase.order_reference
scorerisk.scorecase.risk_score
Martini implementation pattern

Martini exposes a REST API for supported callbacks, validates and normalizes the notification, resolves the related User or Order, and creates or updates the downstream case. Idempotency controls prevent duplicate updates, and malformed or unrecognized callbacks are placed on an operational exception path.

Martini capabilities used
  • API exposure
  • webhook consumption
  • data mapping
  • business rules
  • idempotency handling
  • monitoring

Pattern 4: Load historical Events in controlled batches

When to use this pattern

Use this pattern for migration, backfill, or reconciliation when historical customer or transaction activity must be submitted to Sift through supported event APIs. It is appropriate only after confirming event semantics, limits, and timestamp behavior for the applicable API version.

Integration direction
Source database or application
Martini
Sift
Example Mapping
Sift FieldCanonical FieldTarget Field
source_customer_idcustomer.idSift user identifier
source_transaction_idtransaction.idSift event or order identifier
created_atevent.timestampSift event timestamp
transaction_typeactivity.typeSift Event name
Martini implementation pattern

A scheduled Martini workflow reads from the source using a checkpoint, validates and partitions records, submits controlled batches to Sift, records item-level results, and advances only after durable processing. Backoff, replay protection, and rejected-payload retention support safe recovery from rate limits and partial failures.

Martini capabilities used
  • scheduled workflows
  • database or API consumption
  • batch orchestration
  • mapping and transformation
  • checkpointing
  • retry handling

Applications commonly integrated with Sift

Sift can be integrated with commerce, payment, CRM, case-management, and analytical platforms to submit behavioral activity and apply risk outcomes. These are potential enterprise architecture targets rather than claims of bundled Sift integrations or native Martini connectors.

Application Scenario Direction Martini Pattern
Shopify Evaluate checkout, account, payment, and order activity for fraud and abuse risk before downstream order handling. Shopify → Martini → Sift Martini receives commerce events, maps customer and transaction context to Sift Events, submits them through the REST API, and routes the resulting Decision or Score back to the order workflow.
Salesforce Commerce Cloud Send shopper and transaction activity to Sift and use risk outcomes during order review or fulfillment decisions. Salesforce Commerce Cloud → Martini → Sift A Martini workflow transforms commerce payloads, centralizes Sift authentication and API version settings, submits the event, and updates commerce operations according to the returned outcome.
Adobe Commerce Evaluate customer, cart, payment, and order activity before fulfillment or account actions proceed. Adobe Commerce → Martini → Sift Martini validates required fields, maps Adobe Commerce data into Sift event structures, handles retries and rate limits, and returns approved, review-required, or blocked states to the commerce process.
Stripe Correlate payment and transaction context with Sift risk analysis and route decisions into payment or order operations. Stripe → Martini → Sift Martini receives payment-related activity from the payment orchestration layer, enriches it with customer and order context, submits it to Sift, and persists correlation identifiers and decisions.
PayPal Include PayPal-enabled transaction activity in broader fraud and trust workflows. PayPal → Martini → Sift Martini normalizes payment and order data, sends applicable Events to Sift, separates risk decisions from transport failures, and forwards review outcomes to order operations.
Salesforce Synchronize customer risk outcomes, account status, or review context with CRM operations. Sift → Martini → Salesforce Martini retrieves or receives Sift outcomes, maps User and Decision information to Salesforce objects, applies update rules, and retries transient CRM or Sift failures.
Snowflake Load Sift-related Events, Scores, and Decisions into an analytical environment for reporting and model operations. Sift → Martini → Snowflake Martini retrieves supported Sift data or consumes downstream event outputs, applies a canonical analytical mapping, and writes durable records to Snowflake through the approved data-access path.
ServiceNow Create or update operational and fraud-review cases from Sift Decisions or selected risk notifications. Sift → Martini → ServiceNow Martini receives a Sift callback or retrieves a Decision, validates and enriches the payload, then creates or updates a ServiceNow case with retry and duplicate safeguards.

How to build a Sift integration in Martini

Objective

Configure the Sift API base URL, selected API version, account or environment identifiers where required, and API-key authentication without embedding credentials in workflow definitions.

Instructions in Martini

  • Create environment-specific configuration for Sift endpoints and API versions.
  • Store Sift API keys in Martini Secrets Management.
  • Configure HTTPS requests and common authentication headers.
  • Keep development, testing, and production credentials separate.

Objective

Select a real-time application event, supported Sift callback, or scheduled source read based on the required integration pattern and decision latency.

Instructions in Martini

  • Use an application event for real-time risk evaluation.
  • Expose a Martini REST API for selected Sift callbacks.
  • Use a scheduler for historical loads or reconciliation.
  • Define pending behavior when a decision is not immediately available.

Objective

Collect source activity or Sift responses while preserving identifiers needed to correlate Users, Events, Orders, Scores, and Decisions.

Instructions in Martini

  • Capture stable source and correlation identifiers.
  • Retrieve the current Sift resource when a notification does not contain the full payload.
  • Handle pagination for collection reads where documented.
  • Record the selected Sift API version with the integration configuration.

Objective

Coordinate validation, API calls, conditional routing, batching, and downstream updates in a maintainable Martini workflow.

Instructions in Martini

  • Separate transport failures from Sift business Decisions.
  • Apply controlled concurrency for high-volume submissions.
  • Route accepted, rejected, and retryable items independently.
  • Use reusable workflow logic for common Sift request and response handling.

Objective

Convert source-specific customer, device, transaction, payment, and activity fields into the Sift model while validating event names and required properties.

Instructions in Martini

  • Create versioned mappings for Sift Events and Orders.
  • Normalize timestamps, identifiers, amounts, and enumerated values.
  • Validate required fields before making the Sift request.
  • Minimize sensitive data carried into logs and retained payloads.

Objective

Translate Sift Scores and Decisions into explicit downstream outcomes such as approved, review-required, or blocked without confusing them with API errors.

Instructions in Martini

  • Define score thresholds and decision routing outside request transport logic.
  • Use pending states for asynchronous or callback-driven processes.
  • Apply duplicate and replay rules using stable source identifiers.
  • Record the reason and correlation context for each downstream state.

Common Sift data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
UsersRepresent individuals or accounts evaluated for fraud, abuse, or trust risk.CRM, commerce platforms, case-management systems, analytical platformsMartini maps identity and account context, submits or retrieves applicable User information, and applies privacy and retention controls.
EventsCapture behavioral or transactional activity such as login, account creation, payment, order, or chargeback-related activity.Commerce platforms, payment workflows, security systems, data platformsMartini validates event names and properties, transforms source payloads, submits Events in real time or controlled batches, and records correlation identifiers.
OrdersRepresent purchase or transaction information associated with a User for risk evaluation.Order management, commerce, payment, fulfillment systemsMartini maps order, customer, device, and payment context, submits the applicable payload, and routes the resulting decision to order processing.
DecisionsRepresent risk or policy outcomes such as allowing, reviewing, or blocking an activity.Order management, CRM, case-management, payment operationsMartini treats Decisions as business data, maps them to explicit downstream states, and keeps API failures on separate retry or operational-error paths.
ScoresProvide risk scores and related scoring information for Users, Orders, or Events.Commerce, payment, CRM, analytics, case-management systemsMartini retrieves or receives Scores where supported, applies threshold and routing rules, and persists the score with source and correlation metadata.
AccountsOrganize Sift customer or tenant-level resources, API access, configuration, and related data.Configuration stores, administration workflows, security operationsMartini keeps account and environment configuration externalized, applies environment-specific credentials, and avoids scattering version-specific settings across workflows.

Authentication and security considerations

API-key authentication

Sift uses API-key authentication as its primary integration model. The exact authentication header and API version should follow the current Sift documentation for the applicable endpoint.

Credential protection

  • Store Sift API keys in Martini Secrets Management.
  • Use separate credentials and configuration for development, testing, and production.
  • Use HTTPS for all API communication.
  • Do not place credentials in mappings, scripts, request bodies, or operational logs.

Sensitive data controls

Risk workflows may process personal, payment, device, and behavioral information. Restrict logs, minimize retained payloads, and apply environment and access controls appropriate to the data.

Operational considerations for Sift integrations

Rate limits and retries

High-volume submissions may encounter rate limits or service-protection responses. Use controlled concurrency, backoff, and explicit handling for applicable HTTP 429 responses.

Pagination and checkpoints

Collection reads may be paginated. Continue through the documented cursor or page condition and persist checkpoints for scheduled or historical workflows.

Idempotency and batches

Retries after timeouts can create duplicate submissions. Use stable identifiers and Sift’s documented deduplication guidance. For batches, retain item-level acceptance and rejection results and retry only eligible failures.

Schema and decision handling

Version mappings when event names, required properties, or data types change. Treat allow, review, and block outcomes as business data, separate from authentication, validation, rate-limit, and service errors.

Testing and monitoring

Test representative Users, Events, Orders, Scores, Decisions, callbacks, and failure paths in non-production environments. Monitor workflow logs and preserve correlation identifiers for troubleshooting and reconciliation.

Why use Martini instead of scripts or point-to-point integrations?

Centralized integration logic

Martini centralizes Sift API versions, authentication, request headers, mappings, business rules, and downstream routing instead of scattering them across scripts and point-to-point implementations.

Reliable orchestration

Workflows can coordinate real-time submissions, scheduled synchronization, selected callbacks, controlled batches, retries, validation, and partial-failure handling.

Reusable data transformation

Reusable mappings and workflow components help standardize customer, device, payment, order, Event, Score, and Decision handling across applications.

Operational maintainability

Martini provides structured error paths, environment configuration, secrets management, monitoring, and API exposure so Sift integrations can evolve with versioned payloads and changing business requirements.

Frequently asked questions

How can Sift be integrated with enterprise systems?

Sift is primarily integrated through REST APIs that submit Users, Events, Orders, and payment or behavioral activity and retrieve Scores and Decisions. Sift also supports webhook-style notifications for selected risk or decision use cases, while batch-style event submission may be available for applicable API versions and endpoints.

Can Martini integrate with Sift?

Yes. Martini can consume Sift REST APIs, submit event and transaction data, retrieve risk information, expose a REST API for supported Sift callbacks, and orchestrate downstream actions using workflows, mappings, business rules, retries, and secure API-key configuration.

Do I need a connector to integrate Sift with Martini?

No. A dedicated Sift connector is not required. Martini can integrate using Sift’s confirmed native REST APIs, selected webhook-style callbacks, batch event submission where supported, and API-key authentication.

Is there any extra Lonti cost to integrate Sift with Martini?

Lonti does not charge an additional per-connector or per-vendor fee to integrate Sift. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Sift, cloud infrastructure, or other third-party systems depending on subscription, usage, and deployment model.

Which Sift integration methods should new implementations use?

REST APIs are Sift’s primary and recommended integration method for sending Events and working with Users, Orders, Scores, and Decisions. Selected webhook-style notifications and batch event submission can complement REST APIs when enabled and supported by the applicable product and API version.

Can Martini receive Sift webhooks or callbacks?

Martini can expose a REST API to receive Sift webhook-style callbacks. Sift notification coverage is product- and event-specific, so the enabled decision or risk notifications, payload structure, validation requirements, and retry behavior should be confirmed before implementation.

How are Sift data mappings, synchronization, and duplicates handled?

Martini maps source customer, device, payment, order, and activity data into versioned Sift payloads and can run real-time, scheduled, or batch workflows. Stable source identifiers, checkpoints, correlation identifiers, and documented Sift deduplication guidance help distinguish retries from new Events and support reconciliation.

Can Martini expose an API façade for Sift?

Yes. Martini can expose a controlled REST API that standardizes an organization’s internal request model, applies validation and business rules, calls Sift’s REST APIs, and returns a consistent response. It can also provide a callback endpoint for supported Sift notifications without claiming a native Sift connector.

Related Martini documentation

Sift APIs

Callbacks

Workflows

Security and operations

Connect Sift with Martini

Use Martini to integrate Sift REST APIs, selected callback notifications, and risk workflows with the enterprise systems that depend on trusted transaction and account decisions.

EXPLORE MARTINI
BOOK A DEMO