Aggregate counts across your screened transactions — volumes, how they split by risk level and outcome, and which rules fire most.
Scoped to your organisation.
Authorization
ApiKeyAuth In: header
Response Body
application/json
curl -X GET "https://example.com/api/v1/fraud/transaction-monitoring/transactions/stats/"{ "data": {}, "status": true, "message": "Request successful.", "errors": {}, "meta": { "timestamp": "2019-08-24T14:15:22Z", "version": "v1", "request_id": "string" }, "pagination": { "page": 0, "page_size": 0, "total_pages": 0, "total_items": 0 }}response_code values (e.g., 00 Success, 01 Not Found, 02 Unavailable).Join our developer Slack channel for real-time integration support, engineering updates, and direct Q&A with the Prembly team.
Join Slack ChannelScreen a transaction POST
Scores a transaction against your configured rules and returns a risk assessment. This is the entry point to transaction screening — everything else in this section reads results it produced. The response carries the score (`risk_score`, `risk_level`, `fraud_probability`), the outcome (`status`), and which of your rules fired (`rules_triggered`, `rules_triggered_count`). Keep `internal_reference` — it is how you fetch the transaction again later. Returns `201`: screening creates a stored transaction record, it does not merely evaluate one. Send a sandbox key (`test_sk_` / `test_pk_`) to screen without affecting your production data; sandbox results are filtered out of the live transaction list by the `mode` parameter.
List screened transactions GET
Returns transactions you have screened, newest first. Use `mode` to separate real traffic from testing: `production` returns transactions screened with a live key, `sandbox` those screened with a test key or through the widget. Without it you get both, which is rarely what you want on a dashboard. Results are paginated; combine the date, amount and `risk_level` filters to narrow rather than paging through everything.