Monitoring rules

A report is a snapshot you pull on demand. Monitoring is the opposite: Walker Street Data watches a customer's enriched data as it arrives and sends you a webhook only when something you care about happens - turnover dropping, an account slipping overdrawn, or new borrowing appearing.

Rules and rulesets

A rule is a single true/false condition: one metric compared against a threshold.

days_overdrawn_30d > 5

A ruleset is a named group of rules combined with OR - it is true when any rule is true. A ruleset with one rule is still a ruleset. Rulesets are what you get alerted on: when one becomes true it fires and sends one webhook. Rulesets fire independently.

A set of rulesets for a lender might look like this - each block is a ruleset, the indented lines are its rules:

revenue-drop (ruleset)
    revenue_trend_90d < -0.25
      OR revenue_vs_prior_year < -0.30
      OR declining_months_streak >= 3

overdrawn-account (ruleset)
    days_overdrawn_30d > 5

new-borrowing (ruleset)
    new_loan_inflows_30d > 0
      OR bnpl_repayments_30d > 0

So revenue-drop fires when turnover falls sharply on any of three measures, overdrawn-account when the account sits overdrawn for more than five days in a month, and new-borrowing when new loan drawdowns or BNPL repayments appear. The metrics here are illustrative; your rulesets are configured with Walker Street Data (contact us to set one up) and are not self-service.

When rules run

Rulesets run automatically after enrichment - there is no separate call:

1. Submit transactions for a customer.
2. Once the job enriches them, every active ruleset for that customer is evaluated.
3. Each metric reads back over its own window (days_overdrawn_30d the last 30 days, revenue_trend_90d the last 90, and so on) across the customer's full history, not just the latest submission.
4. Any ruleset that is true fires a monitoring.rule.triggered webhook; ones that aren't true send nothing.

Submitting more transactions later re-evaluates every ruleset over the updated history, so keeping data current keeps monitoring current.

What you receive

One firing sends one webhook, so three rulesets firing on the same evaluation means three deliveries. A ruleset that stays true re-fires on each evaluation.

The payload is the common webhook envelope (eventType, eventId, clientId, customerId, timestamp) plus a ruleset object. It does not carry the job fields (jobId, abn, jobType).

Field	Type	Description
ruleset.id	uuid	Identifier of the ruleset
ruleset.slug	string	Stable machine-readable ruleset slug
ruleset.name	string	Human-readable name of the ruleset

{
  "eventType": "monitoring.rule.triggered",
  "eventId": "b2c3d4e5-f6a7-8901-bcde-f23456789012",
  "clientId": "a0ced7e1-da3a-40ea-a18f-4c829f816c6a",
  "customerId": "524ba9bc-06e7-417e-bd54-b99785f5194a",
  "timestamp": "2026-07-13T02:15:00Z",
  "ruleset": {
    "id": "184ba9bc-06e7-417e-bd54-b99785f5199a",
    "slug": "REVENUE_DROP",
    "name": "Revenue drop detected"
  }
}

The delivery tells you which ruleset fired, not which rule within it. Route on ruleset.slug (stable) rather than ruleset.name (display text that may change); pull a report to see the underlying data.

Subscribing

Notifications use the standard webhook mechanism. Subscribe to the monitoring.rule.triggered event type:

curl -X POST "https://api.walkerstdata.com.au/v1/webhooks/subscriptions" \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "eventType": "monitoring.rule.triggered",
    "webhookUrl": "https://your-app.example.com/webhooks/wsd",
    "customerIds": []
  }'

One subscription receives firings for all rulesets on your account; pass customerIds to scope it, or leave it empty for a catch-all. See Webhooks for scoping, signature verification, and delivery behaviour.

Next steps

• Webhooks - Subscribe, verify signatures, and handle deliveries
• Reports - Pull insight metrics for a customer on demand
• Upload banking data - Feed the data that monitoring runs on