docs(campaign-api): document website and web redirects on campaign PATCH [LIN-2805]

[sakkshm26]

Docs companion to linkrunner-backend#1085 · LIN-2805

Merge after the backend PR ships — it documents fields the endpoint does not accept until then.

Why

A customer reported that PATCH /api/v1/campaigns/{display_id} returns 200 but silently discards website, ios_web_redirect and android_web_redirect. That was accurate: the handler read only name and active off the body. The Edit Campaign section documented only those two fields, so the docs were not wrong so much as documenting a gap — while the Create Campaign section above it accepts all three, which is what made the asymmetry easy to trip over.

Changes

• Add website, android_web_redirect and ios_web_redirect to the request body example and parameter table.
• Document the clear-vs-leave-unchanged convention: an empty string or null clears a field, omitting it leaves the stored value untouched. Added as its own example, since it is the part a caller cannot guess.
• Note that website is the same column Create accepts as link_for_desktop_users, that either spelling works on PATCH, and that sending both with different values is rejected.
• Add the three fields to the success response example — the endpoint now echoes them, which is what lets a caller confirm a write without a second GET.
• Add the two new 400s (invalid redirect URL, conflicting website spellings).
• Add the three fields to the JavaScript example, using ios_web_redirect: "" to show a clear.
• Add a note that these changes reach live campaign links immediately, since the click path's cached copy is cleared as part of the update.

Also corrected

The at-least-one-field 400 row quoted the dashboard's error string:

"At least one field (name, active, website, deeplink, store listing, linkedin, network_account_id, ad_network_id, or custom channel) is required"

That message comes from editCampaignSchema, which backs the session-authenticated PUT /api/campaign — not this endpoint. Replaced with the string this route actually returns.

Flagging, not fixing: custom_channel_names

This section documents custom_channel_names on the PATCH (added in #146, LIN-1956), but the public handler in data.ts contains no custom-channel handling at all — grep custom_channel src/controllers/data.ts returns nothing on backend main. As far as I can tell that parameter is not accepted, and the row describes the dashboard route, same as the error string above.

I left it in place rather than deleting it, since I do not know whether it was documented ahead of a backend change that was intended to follow. Worth a decision from whoever owns LIN-1956 — if it genuinely is not supported, it should come out, and it is the same class of bug as the one this PR documents the fix for.

Verification

npm run check:routes — passes, 102 pages, no unredirected removals.

🤖 Generated with Claude Code

https://claude.ai/code/session_01PbTVbWroJs97joijZE1nQY