Adapter API Ingestion
How Remllo supports customer or provider payloads that do not match the native WatchTower contract.
Why adapters exist
Not every institution can emit the native WatchTower transaction shape. Core banking platforms, fintech ledgers, wallet systems, bill-payment systems, and payment processors often have different field names, timestamp formats, account objects, and event structures.
A Remllo adapter receives a known source payload, validates it, normalizes it into the canonical WatchTower transaction model, and sends it through the same rule engine and operational workflow as direct canonical ingestion.
What adapter mapping does
- maps source transaction IDs into WatchTower references
- normalizes amount, currency, timestamp, channel, and direction
- maps sender/customer and receiver/counterparty objects
- preserves source-specific references in metadata
- keeps tenant routing and organization boundaries explicit
- allows optional enrichment without making identity a hard dependency
Source payload
-> Remllo adapter validation
-> canonical transaction model
-> rules and behavioral analysis
-> decision response
-> alerts, cases, notifications, reportsPublic adapter contract
The public route shape is stable, but each adapter key represents a contract agreed between Remllo and the integrating institution or platform. Remllo shares adapter-specific payload contracts privately during implementation.
The public docs explain the adapter pattern. They intentionally do not publish private provider payload contracts, scoring logic, or tenant-routing details.
Example source payload
The shape below is illustrative only. Real adapter contracts are agreed during onboarding and may differ depending on the customer or source platform.
{
"eventId": "evt_2026_00145",
"eventType": "transaction.created",
"occurredAt": "2026-03-24T14:43:46.020Z",
"transaction": {
"reference": "SRC-778812",
"amount": 25000,
"currency": "NGN",
"channel": "mobile_app",
"direction": "outbound",
"category": "transfer",
"narration": "Family support"
},
"customer": {
"id": "cus_12345",
"name": "Ada Okafor",
"accountNumber": "0123456789"
},
"counterparty": {
"name": "Bayo Musa",
"accountNumber": "0987654321",
"bankCode": "214"
},
"device": {
"id": "device_9f24",
"ipAddress": "203.0.113.42"
},
"metadata": {
"sourceSystem": "example-ledger",
"tenantReference": "tenant_001"
}
}Adapter readiness checklist
- agree the source payload contract
- confirm tenant routing and organization mapping
- define required and optional fields
- test allow, review, and block-style scenarios
- confirm idempotency and duplicate behavior
- confirm the transaction appears correctly in alerts, cases, and reports