Skip to main content
This guide covers the bill pay rules API — creating rules, understanding the condition AST structure, configuring actions, and managing rule lifecycle.

Endpoints

Rule structure

A rule consists of:
  • name — human-readable label
  • description — optional explanation of the rule’s purpose
  • phase — either ROUTING or GL_CODING
  • isActive — whether the rule is currently being evaluated
  • priority — evaluation order (lower numbers evaluate first)
  • conditionAst — the condition tree (see below)
  • actions — array of action objects

Condition AST

Conditions are expressed as an abstract syntax tree (AST) with four node types:

COMPARE node

Tests a single field against a value:

AND node

All children must match:

OR node

Any child can match:

NOT node

Inverts the child:

Condition fields

Operators

Action types

Routing rule actions

GL coding rule actions

Creating a rule (example)

Rule evaluation behavior

  • Rules are evaluated in priority order (lower number = higher priority)
  • All matching rules fire — evaluation doesn’t stop at the first match
  • Actions are deduplicated by destination — if two rules route to the same destination, delivery happens only once
  • GL coding rules evaluate before routing rules in the same pass
  • A rule with no conditions matches every bill (acts as a catch-all)

Decisions (evaluation results)

After evaluation, each bill gets a decision record accessible via the decisions endpoint. The decision includes:
  • Which rules were evaluated
  • Which rules matched (with full condition trace)
  • What actions fired and their delivery status (PENDING, APPLIED, DELIVERED, FAILED)