Transaction Ingestion
How to structure transaction payloads and how WatchTower evaluates them.
Real-time ingestion
Send transaction events with organization-scoped API keys and idempotency protection.
Detection context
Richer sender, receiver, device, and metadata fields improve monitoring and fraud-detection quality.
Operational outcomes
Every request can contribute to decisions, alerts, cases, onboarding milestones, and reporting flows.
Ingestion contract
WatchTower ingests transaction events as JSON. Start with a minimal useful payload, then expand as your detection model matures.
Minimum useful fields
- transaction ID
- amount
- currency
- channel
- transaction type
- timestamp
- sender details
- receiver details
Why richer payloads matter
Additional device, behavior, and metadata fields improve detection quality. If you send only a minimal payload, WatchTower still evaluates the transaction, but more advanced controls will have less context to work with.
Useful enrichment fields
- device data
- behavior counters
- account age
- geography
- metadata flags
Safe retries with idempotency
Always send an idempotency key header for ingestion requests. This protects your integration when your system retries after timeouts, network interruptions, or transient upstream errors.
What happens after ingestion
Each ingestion request returns a decision outcome with supporting context. Depending on the payload and the triggered controls, WatchTower can also create alerts, case activity, audit events, and downstream operational signals.
Recommended rollout pattern
- device information
- behavioral counters
- customer metadata
- geography and corridor context
Start with a minimal working payload, then iteratively add richer context. That gets teams live quickly without blocking future signal depth.