## TL;DR
Routing rules match on conversation attributes, and webhook-created conversations carry whatever your payload sent, which is often less than the rule expects. If the rule wants a tag, a language, or a custom field that the webhook never sets, it never matches. The fix is to compare the rule's conditions against a real webhook conversation's attributes and close the gap on whichever side is wrong.

## The query

```text
dixa routing rule not triggered on webhook
```

## Use this when

- A routing rule never fires for webhook-created conversations
- Webhook conversations sit unassigned in the queue
- A new rule fires for nothing at all


## Not for

- Dixa API authentication errors
- No agents available to receive routed chats
- Dixa widget loading issues


## Steps

### 1. Inspect a real webhook conversation's attributes

Open an unrouted webhook conversation and read its actual attributes: tags, language, custom fields, channel. Compare each against the rule's conditions. The mismatch is usually obvious once you see both side by side.

Expected output: the rule's expected attributes next to the conversation's actual ones.

### 2. Fix the rule or the payload, not both randomly

If the rule is right, add the missing attributes to the webhook payload at creation. If the payload is right, loosen the rule. Changing both without knowing which was wrong creates a rule that fires for the wrong conversations.

Expected output: one deliberate change with a stated reason, then a retest.

### 3. Check rule order and exclusivity

An earlier rule may be grabbing the conversation first, or the rule may be set to stop processing after a match elsewhere. Review the rule list top to bottom with a test conversation.

Expected output: the test conversation landing on the intended rule and no other.

### 4. Test with the webhook, not the UI

Manually creating a test conversation in the UI sets attributes the webhook doesn't. Always test routing with a real webhook call carrying a production-shaped payload.

Expected output: a webhook-created test conversation routing correctly end to end.

## Variant phrasings

### dixa conversation not routed automatically

Steps 1 and 2: compare attributes, fix the right side.

### dixa routing rule conditions webhook

Step 4's test discipline catches payload-vs-UI differences.

## Why it happens

Routing rules are written against the Platonic conversation: tagged, languaged, fully attributed. Webhook conversations are whatever your code sent, which is the minimum viable payload someone wrote at 5pm. The rule is fine; it's matching against data that was never there.

## Edge cases

- Rule changes need retesting with webhooks. UI tests lie about webhook payloads.
- Multiple webhooks creating conversations need consistent payloads or per-source rules.
- Dixa evaluates rules at creation time. Attributes added later don't retrigger routing.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_8lFMoS1YBthO0DAVhM7IxA