fetch_drips
List the account drip campaigns — automated email or SMS sequences — with their status, people counters and the plan allowance. Defaults to 25 per page, maximum 100. The counters here count PEOPLE in the sequence (enrolled, active, completed, exited), NOT messages: never report "1,240 sent" from an Enrolled of 1,240. Counters is NOT four numbers: Enrolled, Active and Completed are counts, but Exited is an OBJECT keyed by the same nine reasons as ExitReason in fetch_drip_enrollments (Unsubscribed, Suppressed, NoConsent, Removed, Clicked, Won, Invalid, Undeliverable, OverQuota), and Deferred is an object with Capped and OverQuota. The documented field table calls Exited "by reason" without naming the keys; the nine above are the ones ExitReason enumerates and the shape was confirmed on a live drip 2026-10-13. Add the object up if the user wants one number, and never print it as though it already were one. Message statistics live in fetch_drip_report only. Contact addresses never appear in any drip response. The response carries can_run, which the API documents as whether the PLAN lets drips be activated or resumed — a false there does NOT mean the module is disabled, so never report it as one. Alongside it, plan_limit is passed through in PascalCase and gives MaxAllowed (0 means unlimited), CurrentCount, LimitReached and Unlimited (true when the plan sets no drip limit, that is MaxAllowed 0); LimitReached true means no further drip can be created, which is an app action anyway. can_run is INDEPENDENT of those counters — it was observed false on a live account while CurrentCount was 0 and LimitReached was false, so never explain a false can_run by the allowance. It tells you THAT the plan does not allow it, never WHY: the cause only surfaces when a write is refused, and what a refusal actually carries has now been measured — a pause refused on a draft answered 409 with api_data.Status naming the status, NOT a Reason (verified live 2026-10-13). The documented Reason vocabulary (PlanDoesNotAllowSharing, ChannelNotInPlan, NoRegisteredSmsSender, StaffHold) has still never been seen on a real response, so read the message and never claim a Reason the response did not include. Do not guess between them from can_run alone. Account-gated, and the two sides of this category are gated differently: the reads need only the Drip Marketing module, while pause_drip, resume_drip and remove_drip_contact need Drip Marketing plus Send Message. The gate was NOT observed on the test account, so on a 403 read back which module the API named instead of guessing. Drips are created, edited, activated and deleted ONLY in the Sweeppea app: those actions run a launch checklist (template, sender, 10DLC registration, content screening, plan allowance) that this API deliberately does not reproduce. There is no create endpoint and that is by design, not a gap — the API leaves these writes out on purpose (confirmed by the API maintainer, October 2026) — say so plainly instead of hunting for a workaround, and never propose or invent a tool for it.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number, starting at 1. Defaults to 1 | |
| search | No | Part of the drip name (case-insensitive, max 100 characters) | |
| status | No | Drip status to filter by. Note this list differs from the one used by fetch_drip_enrollments | |
| channel | No | email or sms | |
| archived | No | true lists archived drips instead. Defaults to false | |
| items_per_page | No | Results per page, 1 to 100. Defaults to 25 | |
| sweepstakes_token | No | Only drips of this sweepstakes (UUID v4) |