# Dunning Follow-Up
Read failed-payment accounts via API and email dunning follow-ups to at-risk customers to recover revenue before involuntary churn.

## When to use
- A billing/payment provider reports new failed or past-due invoices.
- A recurring revenue-operations sweep for accounts stuck in a dunning (payment-retry) cycle.
- A customer's card has expired or been declined and no follow-up has been sent yet.
- Finance or a human teammate asks for an updated list of at-risk accounts.

## Tools
- `http-get`: reads failed-payment and past-due account data from the billing provider's API.
- `write-file`: drafts the dunning follow-up email copy and the at-risk account summary before sending.
- `send-email`: delivers the dunning follow-up message to the affected customer.

## Playbook
1. Call the billing provider REST API with `http-get` (e.g. GET https://api.stripe.com/v1/invoices?status=past_due). Authentication is injected by the org's Integration row for this host — never ask for, echo, or hardcode credentials. If the call returns 401/403 or no Integration row exists, stop and message a human via `send-message` asking them to create the Integration, naming the service and required scopes.
2. Parse the response and build a list of at-risk accounts: customer name, email, amount owed, failure reason, and retry date.
3. For each account, check whether a follow-up was already sent recently; skip accounts already contacted within the cooldown window.
4. Draft the dunning email copy for each remaining account, including the outstanding amount and a clear payment-update call to action.
5. Save the draft copy and the at-risk account summary to a file with `write-file` for record-keeping and audit.
6. Send each dunning follow-up email to the customer with `send-email`, personalizing the amount owed and due date.
7. If the API response is empty, re-verify the endpoint URL and status filter before concluding there are no at-risk accounts.
8. Note any accounts that require a payment plan change, refund, or record update — this requires PATCH/PUT/DELETE on the billing system, which is NOT POSSIBLE with the declared tools. Compile the change list to a file with `write-file` and hand off to a human via `send-message`; never imply the update was made.
9. Summarize the outcome — accounts identified, emails sent, and any handed-off items — via `complete-task`.

## Failure modes
- 401/403 response -> missing Integration for the billing host; stop and escalate via `send-message` naming the service and required scopes.
- Empty result set -> verify the endpoint URL, status filter, and pagination parameters before assuming no at-risk accounts exist.
- Rate limit (429) response -> back off and retry later; note the limit in memory via `update-memory` so future runs pace requests.
- Record needs an update the API can't perform read-only -> stop, write the change list to a file, and hand off to a human via `send-message`.

## Done when
- The at-risk account summary file exists via `write-file` and lists every account pulled from the billing API.
- Every eligible at-risk customer has received a dunning follow-up email via `send-email`.
- Any accounts requiring a write-side update are documented and handed off to a human, and the task is closed via `complete-task`.