# Update Webhook notification channel

Update the configuration of an existing Webhook notification channel

Endpoint: PATCH /notification_channels/webhook/{notification_channel_id}
Version: 1.0.0
Security: ApiKeyAuth

## Path parameters:

  - `notification_channel_id` (string, required)
    Unique identifier (UUID) of the notification channel.
    Example: "550e8400-e29b-41d4-a716-446655440000"

## Request fields (application/json):

  - `name` (string)
    User-defined human-readable name for the notification channel.

Used to identify and distinguish between different notification channels.
The name should be descriptive and help users understand the purpose
or destination of the channel.
    Example: "Production Alerts Webhook"

  - `url` (string)
    HTTP/HTTPS URL endpoint where notification webhooks will be sent.

The URL must be accessible from the notification service and should
accept POST requests with JSON payloads. Only HTTP and HTTPS protocols
are supported for security reasons.

Security Note:
URLs containing sensitive information (API keys in query params)
should use headers for authentication instead.
    Example: "https://api.example.com/webhooks/notifications"

  - `headers` (object)
    Optional HTTP headers to include with webhook requests.

Commonly used for:
- Authentication: "Authorization: Bearer token"
- Content type: "Content-Type: application/json"
- API keys: "X-API-Key: your-api-key"
- Custom headers for routing or identification

Security Note:
Sensitive headers (tokens, API keys) should be handled securely
and may be masked in API responses.
    Example: {"Authorization":"Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...","Content-Type":"application/json","X-API-Key":"your-secret-api-key"}

## Response 200 fields (application/json):

  - `id` (string, required)
    Unique identifier in UUID format
    Example: "550e8400-e29b-41d4-a716-446655440000"

  - `kind` (string, required)
    Defines the type of notification delivery channel.

Each kind determines the transport mechanism and configuration structure:
- nats — NATS subject-based messaging for internal microservice communication
- telegram — Telegram bot message delivery to chats or direct messages
- webhook — HTTP POST callbacks to external endpoints
    Enum: "nats", "telegram", "webhook"

  - `name` (string, required)
    User-defined human-readable name for the notification channel.

Used to identify and distinguish between different notification channels.
The name should be descriptive and help users understand the purpose
or destination of the channel.
    Example: "Production Alerts Webhook"

  - `config` (object, required)
    Configuration structure for notification channels. The exact schema depends on the channel kind.

Each channel type has specific configuration requirements:
- NATS channels require a subject for message routing
- Telegram channels require bot token and chat ID for message delivery
- Webhook channels require URL and optional headers/authentication

  - `is_archived` (boolean, required)
    Indicates whether the notification channel is archived (disabled)

  - `created_at` (string, required)
    Timestamp when the resource was created
    Example: "2024-01-15T10:30:00Z"

  - `updated_at` (string, required)
    Timestamp when the resource was last updated
    Example: "2024-01-15T10:30:00Z"

## Response 400 fields (application/problem+json):

  - `type` (string, required)
    A URI reference that identifies the problem type
    Example: "https://docs.vilna.io/apis/problems/invalid-request"

  - `title` (string, required)
    A short, human-readable summary of the problem type
    Example: "Invalid Request"

  - `status` (integer, required)
    The HTTP status code
    Example: 400

  - `detail` (string)
    A human-readable explanation specific to this occurrence of the problem
    Example: "Validation error"

  - `instance` (string)
    A URI reference that identifies the specific occurrence of the problem
    Example: "/errors?id=XXXXXX-xxxxx"

  - `fields` (array)
    List of invalid fields in the request

  - `fields.name` (string, required)
    The name of the invalid field
    Example: "meta"

  - `fields.reason` (string, required)
    Why this field is invalid
    Example: "Exceeded maximum data size — must not exceed 1000 characters"

## Response 404 fields (application/problem+json):

  - `type` (string, required)
    A URI reference that identifies the problem type
    Example: "https://docs.vilna.io/apis/problems/not-found"

  - `title` (string, required)
    A short, human-readable summary of the problem type
    Example: "Not Found"

  - `status` (integer, required)
    The HTTP status code
    Example: 404

  - `detail` (string)
    A human-readable explanation specific to this occurrence of the problem
    Example: "The requested resource was not found"

  - `instance` (string)
    A URI reference that identifies the specific occurrence of the problem
    Example: "/errors?id=XXXXXX-xxxxx"

## Response default fields (application/problem+json):

  - `detail` (string)
    A human-readable explanation specific to this occurrence of the problem
    Example: "An unexpected error occurred while processing your request"

  - `instance` (string)
    A URI reference that identifies the specific occurrence of the problem
    Example: "/errors/1234567890"

  - `status` (integer, required)
    The HTTP status code
    Example: 500

  - `title` (string, required)
    A short, human-readable summary of the problem type
    Example: "Internal Server Error"

  - `type` (string, required)
    A URI reference that identifies the problem type
    Example: "https://api.vilna.io/problems/internal-error"