# CreateWebhookSubscriptionInput

Input object

Input for the createWebhookSubscription mutation.

## Fields

| Name | Type | Required | Default | Description |
| --- | --- | --- | --- | --- |
| `eventTypes` | `[String!]` | No | `["content_view.item_added"]` | Event types to subscribe to. Defaults to [content_view.item_added], the only subscribable type in v1. |
| `metadata` | [`JSON`](/api/v2/docs/types/json) | No | `{}` | Opaque JSON object echoed back verbatim as subscription_metadata on every delivery envelope. Use it to carry your own reference IDs. Capped at 4 KB serialized. Pass an object, not a stringified blob. |
| `name` | `String!` | Yes | — | Display name for the subscription. |
| `url` | `String!` | Yes | — | HTTPS endpoint deliveries are POSTed to. Validated against SSRF ranges. |
| `viewIds` | `[ID!]` | No | `[]` | Content View (FilterPreset) UUIDs whose newly matching items trigger deliveries. Required when any subscribed event type is view-scoped, which is every subscribable type in v1: pass at least one UUID, each owned by the workspace. Must be omitted for non-view event types (none are subscribable yet). v1 ships one event type (content_view.item_added), so express each condition you want to be notified about (verified mentions, usage-rights approved, high EMV, and so on) as a Content View whose filters encode that condition, then point viewIds at it. |
