CDP-6131: make triggerBroadcast data and recipients optional

[thethp]

Summary

The README documents both data and recipients as optional for api.triggerBroadcast(), but the signature declared them as required positional arguments. Two failure modes:

1. api.triggerBroadcast(4) — recipients is undefined, so recipients[field] throws a TypeError
2. api.triggerBroadcast(4, {}, {}) — the empty recipients object is forwarded to the API, which rejects it with a 422 (empty recipients filter is not valid)

Both params are now optional, and empty/omitted data/recipients are left out of the payload, so triggering a broadcast with just its id sends to the broadcast's configured recipients as documented.

Test plan

• New ava cases: broadcastId only, data without recipients, and empty {} objects for both
• npm test — 253 tests pass, coverage stays at 100%
• npm run lint and npm run build clean

Fixes CDP-6131

🤖 Generated with Claude Code

---

Note

Medium Risk
Changes broadcast trigger request payloads and call signatures; incorrect positional args could still mis-route recipients as liquid data, but behavior now matches documented API.

Overview
Makes data and recipients optional on APIClient.triggerBroadcast so a broadcast can be triggered with only an ID, matching the README and Customer.io API behavior (configured recipients).

Payload building now omits empty or missing data/recipients instead of always sending them—fixing a TypeError when recipients was undefined and 422 errors from forwarding {} as recipients. Recipient-only calls must pass undefined for data because arguments are positional.

README adds examples and a note about that positional caveat; new Ava tests cover ID-only, partial args, and empty objects.

^{Reviewed by Cursor Bugbot for commit 17c6112. Bugbot is set up for automated code reviews on this repo. Configure here.}

[thethp]

Addressed the positional-ambiguity feedback in 17c6112: triggerBroadcast(1, { emails: [...] }) still type-checks but sends the selector as liquid data, triggering the broadcast's configured recipients. Since data can legitimately contain keys like emails, a runtime guard would reject valid calls — so this is addressed by documentation and a pinned test instead:

• JSDoc and README now explicitly document the undefined placeholder pattern: triggerBroadcast(1, undefined, { emails: [...] })
• New test asserts the recipients-without-data call sends the selector as a recipient filter (not as data)

254 tests passing, lint and build clean.