Sync a link's analytics IP exclusion list
EAS-82: replaces the link's whole IP exclusion list (whole-set sync, same convention as setLinkRules) — lets a team mark their own preview/test IPs or CIDR ranges so that traffic stops inflating reported reach. A visitor whose client IP matches any entry has their click skipped entirely at record time: never written to clicks history, never counted toward the link's click total, never delivered as a click webhook or live click-stream event, and never attributed a conversion — as if the request never happened, not merely filtered out of reports afterward. Every other gate a redirect goes through (liveness, usage caps, password, screening, retargeting consent) is unaffected; only what gets analyzed afterward changes. An actual change to the list is audited as link.excluded_ips_updated; re-sending an unchanged list is not an event. Each entry's range must be at least /24 for IPv4 or /64 for IPv6 (400 otherwise) — this excludes a team's own IPs, not a link's whole audience, so an accidental near-catch-all like /0 or /4 is rejected rather than silently zeroing out a link's analytics.
View as MarkdownAuthorization
bearer In: header
Path Parameters
Request Body
application/json
TypeScript Definitions
Use the request body type in TypeScript.
Response Body
application/json
application/json
application/json
application/json
application/json
application/json
application/json
curl -X POST "https://example.com/v1/links/string/excluded-ips" \ -H "Content-Type: application/json" \ -d '{ "entries": [ { "cidr": "string" } ] }'{ "excludedIps": [ { "cidr": "string", "label": "string" } ], "warnings": [ "string" ]}Delete one routing rule
Removes one routing rule. Deleting a rule can only ever decrease the split-weight sum, so unlike create/update there's no invariant to recheck here.
Submit a password for a password-protected link (public, unauthenticated)
Checks a visitor-supplied password against a password-protected link's stored hash. On success, returns a short-lived, link-scoped signed token to append as ?lt=<token> on the next GET /{code} to complete the redirect (see that route's description). The token is never a cookie or a session — it carries no server-side state and is reusable until it expires. Same liveness checks as GET /{code} (active, not archived, not expired) apply before the password is even compared; a link with no password configured, or one that fails those checks, responds 404 identically to an unknown code.