[Feature]: Admin API endpoint for org-level domain blocklists (web search/fetch)

Feature Request

Problem

The Anthropic Console supports org-level domain restrictions for web search and web fetch tools (Settings → Privacy). These act as a ceiling — request-level blocked_domains can only further restrict, not expand beyond org settings. This is the right architecture.

The problem: there's no API to manage the org-level list, and the list doesn't scale to real-world security blocklists.

We assembled a deduplicated blocklist from 8 curated upstream sources (Steven Black, URLhaus, Phishing Army, Spam404, and others). The result: 196,000+ unique malware/phishing/scam domains. This can't be pasted into a Console text field or passed as request-level blocked_domains.

Current workaround

We split into two layers:

| Layer | Mechanism | Scale | Automated? |
|-------|-----------|-------|------------|
| Console UI | Hand-curated policy domains (competitors, internal) | Dozens | No — manual |
| Claude Code hook | PreToolUse hook reads local blocklist file, blocks WebFetch to malicious domains | 196k+ | Yes — script refreshes from upstream |

The hook works but only covers Claude Code. API consumers (our Next.js app) have no equivalent — blocked_domains at request level isn't practical at this scale.

Proposed solution (any of these would work)

1. Admin API endpoint — POST /v1/organizations/domain_restrictions accepting a domain list. Matches the existing Admin API pattern for managing org resources programmatically.

1. Blocklist URL subscription — Console setting that accepts a URL to a published blocklist (like Pi-hole does with OISD/Steven Black). Anthropic fetches and applies it on a schedule.

1. Built-in category toggles — Console toggles for common categories (malware, phishing, adult, gambling) backed by Anthropic-curated lists. Lowest maintenance for customers.

Option 3 would eliminate the need for customers to manage blocklists entirely. Option 1 gives maximum flexibility. Option 2 is the middle ground that leverages existing community-maintained lists.

Context

• The web search/fetch domain filtering docs acknowledge org-level restrictions exist but provide no API surface
• The Admin API currently covers members, invites, workspaces, and API keys — domain restrictions would be a natural addition
• Request-level blocked_domains has no documented limit but is impractical at 196k+ domains per request