# `Accrue.Integrations.Chimeway`
[🔗](https://github.com/szTheory/accrue/blob/accrue-v1.5.1/lib/accrue/integrations/chimeway.ex#L34)

Off-by-default Chimeway dunning engine adapter for Accrue (DUN-03).

Conditionally compiled: when the optional `:chimeway` dep is absent
(the default build), this `defmodule` block is elided entirely and
`Accrue.Integrations.Chimeway` is never defined. See the file header
comment for the full 4-pattern rationale.

## Opting in

Add to the host `mix.exs`:

    {:chimeway, "~> 1.0"}

Then configure in `config/config.exs`:

    config :accrue, dunning: [engine: Accrue.Integrations.Chimeway]

The host must also start Chimeway in their supervision tree and run
Chimeway's own migrations per Chimeway's install guide.

## Phase 58 workflow + Signal bridge

Email-only dunning with a two-step Chimeway workflow (initial email → 48h
`wait_until` → escalation email). `DunningNotifier` implements `workflow/2`
and `rendering/2` so `Chimeway.trigger/3` creates a durable `WorkflowRun`
with explainable progression.

Outcome Signal termination: `cancel_campaign/3` emits `Chimeway.Signal.track/4`
with `event_name: "invoice.paid"` and `actor_id` equal to the durable identity
selected by `DunningNotifier.recipients/1`. Chimeway versions exposing the
privacy-safe recipient-reference boundary use a stable opaque customer reference;
Chimeway 1.0 retains its legacy email identity for backward compatibility. Chimeway routes
that `invoice.paid` signal to runs waiting on the wait step via
`Workflows.route_signal/1` — no host callback glue.

`orchestration/2` remains `{:ok, :immediate}` — email delivery planning is
unchanged; workflow progression is driven by `workflow/2`.

---

*Consult [api-reference.md](api-reference.md) for complete listing*
