Webhook connectors in Kibana hand alert payloads to ticketing systems, chat relays, incident routers, and custom HTTP endpoints instead of keeping notifications inside Kibana. Reusing one connector across multiple rules also keeps the destination URL and authentication details in a single managed object.

Current Kibana stores connectors per space as saved objects and manages them from Stack Management → Connectors. The same connector can also be created with the public Actions API, which is useful when you want repeatable connector ids, scripted rollouts, or the same setup path across multiple Kibana environments.

Before creating the connector, make sure Kibana has a fixed xpack.encryptedSavedObjects.encryptionKey, the target hostname is permitted by xpack.actions.allowedHosts, and any custom proxy, CA, or TLS behavior is defined with xpack.actions.customHostSettings when the endpoint needs it. Some connector types are also license-dependent, so it is worth checking that .webhook is enabled before you send the create request.

Related: How to set Kibana encryption keys
Related: How to create Kibana alerts from Elasticsearch data

Steps to create a Kibana webhook connector:

  1. Set the Kibana URL, any optional base-path or space prefix, the connector id, and the authentication header for the target deployment. 
    $ export KIBANA_URL="https://kibana.example.net:5601"
$ export KIBANA_BASE_PATH=""
$ export KIBANA_SPACE_PATH=""
$ export KIBANA_CONNECTOR_ID="ops-webhook-basic"
$ export KIBANA_ACTIONS_BASE="$KIBANA_URL$KIBANA_BASE_PATH$KIBANA_SPACE_PATH/api/actions"
$ export KIBANA_CONNECTOR_TYPES_API="$KIBANA_ACTIONS_BASE/connector_types"
$ export KIBANA_CONNECTOR_API="$KIBANA_ACTIONS_BASE/connector"
$ export KIBANA_AUTH_HEADER="Authorization: ApiKey BASE64_ENCODED_API_KEY"
$ export KIBANA_CA="/etc/kibana/certs/http-ca.crt"

    For a non-default space, set KIBANA_SPACE_PATH to /s/<space_id> so the API targets the correct space, for example /s/ops.

    If the deployment uses basic authentication instead of an API key, replace --header "$KIBANA_AUTH_HEADER" in the later commands with --user kibana_admin:password.

    Keep any configured server.basePath in KIBANA_BASE_PATH. Omitting it is a common reason Kibana API calls return proxy or routing errors.

    Related: How to create a Kibana space

  2. Confirm the current deployment exposes the .webhook connector type before you create the connector object. 
    $ curl --silent --show-error --fail \
  --cacert "$KIBANA_CA" \
  --header "$KIBANA_AUTH_HEADER" \
  "$KIBANA_CONNECTOR_TYPES_API" | jq '.[] | select(.id == ".webhook") | {id, name, enabled, enabled_in_config, enabled_in_license}'
{
  "id": ".webhook",
  "name": "Webhook",
  "enabled": true,
  "enabled_in_config": true,
  "enabled_in_license": true
}

    Current Elastic docs expose the type list at /api/actions/connector_types and include whether the connector is enabled in both configuration and license.

    An empty result or enabled_in_license: false means the deployment cannot create this connector type yet, even if the rest of the alerting UI is available.

  3. Create the webhook connector with the current public API. 
    $ curl --silent --show-error --fail \
  --cacert "$KIBANA_CA" \
  --header "$KIBANA_AUTH_HEADER" \
  --header "kbn-xsrf: true" \
  --header "Content-Type: application/json" \
  --request POST "$KIBANA_CONNECTOR_API/$KIBANA_CONNECTOR_ID" \
  --data @- <<'EOF' | jq '{id, name, connector_type_id, is_missing_secrets}'
{
  "name": "Ops webhook",
  "connector_type_id": ".webhook",
  "config": {
    "url": "https://hooks.example.net/elastic/alerts",
    "method": "post",
    "hasAuth": true,
    "authType": "webhook-authentication-basic",
    "verificationMode": "full"
  },
  "secrets": {
    "user": "webhook-client",
    "password": "change-me"
  }
}
EOF
{
  "id": "ops-webhook-basic",
  "name": "Ops webhook",
  "connector_type_id": ".webhook",
  "is_missing_secrets": false
}

    Current Kibana API docs use a caller-supplied connector id in the request path, so the create call goes to /api/actions/connector/<id> rather than the older no-id create path. The kbn-xsrf header is required for this non-GET Kibana API request.

    For webhook basic authentication, set hasAuth to true, authType to webhook-authentication-basic, and provide the user name and password under secrets.

    If the connector saves but later executions fail, check the webhook hostname against xpack.actions.allowedHosts and add any required CA, proxy, or TLS overrides with xpack.actions.customHostSettings.

    Related: How to set Kibana encryption keys

  4. Fetch the connector details and confirm Kibana stored the expected request settings. 
    $ curl --silent --show-error --fail \
  --cacert "$KIBANA_CA" \
  --header "$KIBANA_AUTH_HEADER" \
  "$KIBANA_CONNECTOR_API/$KIBANA_CONNECTOR_ID" | jq '{id, name, connector_type_id, config: {url: .config.url, method: .config.method, hasAuth: .config.hasAuth, verificationMode: .config.verificationMode}}'
{
  "id": "ops-webhook-basic",
  "name": "Ops webhook",
  "connector_type_id": ".webhook",
  "config": {
    "url": "https://hooks.example.net/elastic/alerts",
    "method": "post",
    "hasAuth": true,
    "verificationMode": "full"
  }
}

    Kibana does not return secret values in this response, so seeing is_missing_secrets: false during creation and the expected non-secret config here is the normal confirmation pattern.

    Use this same connector id when you attach the connector to rule actions in the same space.

  5. Open Stack Management → Connectors, select the new connector, click Test, and send a small JSON payload to confirm the remote endpoint accepts the request. 
    {
  "short_description": "Elastic alert test",
  "description": "Webhook connector test from Kibana"
}

    Current Kibana lets you test the connector while creating or editing it, and the webhook test form sends a raw JSON body to the configured URL.

    When you later use the connector from alert rules, Mustache variables such as {{context.rule.name}} are escaped so the final request body stays valid JSON.

    A failed test usually points to endpoint authentication, xpack.actions.allowedHosts, proxy reachability, or TLS trust settings rather than a problem with the saved connector object itself.

    Related: How to create Kibana alerts from Elasticsearch data