For AI agents: the complete documentation index is available at https://docs.flezise.com/llms.txt, the full documentation bundle is available at https://docs.flezise.com/llms-full.txt, and this page is available as Markdown at https://docs.flezise.com/integrations/webhook.md.
Docs

Webhook ingress

Every inbound event from a connected provider arrives at one of two HTTP routes, is signature-verified, deduplicated, classified into an intent, and either dispatched to a worker or recorded as ignored. This page describes that pipeline.

Routes

Flezise exposes two routes for inbound webhooks:

RouteWhen to use
POST /hooks/{provider}/{connection_id}Per-connection webhooks. Register this URL in your provider's webhook settings. Each connection gets its own URL.
POST /hooks/{provider}App-level webhooks for providers that use a single endpoint per installation. Flezise routes by workspace ID inside the payload.

The {provider} segment is the provider ID in lowercase: github, gitlab, bitbucket, jira, linear, slack, teams, confluence, or microsoft.

Copy the per-connection URL from the Webhook URL field on the integration detail page. For app-level providers (Slack and Linear), the URL is fixed and does not change when a connection is updated or deleted.

Signature verification

Every delivery is verified before processing. The method depends on the provider:

SchemeProvidersHow it works
hmac_sha256GitHub, GitLab (shared token), Bitbucket, Confluence, LinearHMAC-SHA256 of the raw request body, compared to the value in the provider's signature header
shared_tokenGitLab (token connect)Constant-time comparison of a header value against the stored signing secret
ms_graphMicrosoft Teams, Microsoft 365Microsoft Graph subscription validation handshake; clientState field compared against the stored secret
url_tokenJiraNo body signature. The 122-bit connection ID in the URL path authenticates the delivery.

For hmac_sha256 providers, the signature header and prefix vary:

ProviderHeaderPrefix
GitHubx-hub-signature-256sha256=
Bitbucketx-hub-signaturesha256=
Confluencex-atlassian-webhook-signaturesha256=
Linearlinear-signature(none)
GitLabx-gitlab-token(none, shared token scheme)

A delivery that fails verification returns HTTP 401. A delivery from an unknown provider returns HTTP 404.

Warning

Jira webhook URLs contain the connection ID and act as the authentication credential. Do not expose them in logs or share them publicly. Rotate by deleting the connection and reconnecting.

Deduplication

Flezise deduplicates each delivery using two keys:

Delivery key. The provider's idempotency header if present:

ProviderHeader
GitHubx-github-delivery
Bitbucketx-request-uuid
Jirax-atlassian-webhook-identifier
Confluencex-atlassian-webhook-identifier
Linearlinear-delivery

Semantic key. For work_ticket and sync_issue intents, Flezise uses the entity ID extracted from the payload. This collapses repeated deliveries for the same entity into one work item.

When a delivery matches an existing trigger event by either key, the route returns {"ok": true, "duplicate": true} and takes no further action.

Classification and dispatch

Once verified, the event body is passed to a per-provider classifier that resolves the event type and maps it to an intent. Common intents:

Intent actionWhat it means
work_ticketCreate or update a work item from an issue or ticket
sync_issueSync an issue update to an existing work item
fix_ciStart a run to fix a failing CI pipeline
address_reviewStart a run to address a pull or merge request review
answer_questionStart a run to answer a comment or mention

Events that produce no intent are recorded as ignored. Events that produce an intent are checked against the project's automation policy before a work item is created. When the policy blocks the event, its status is set to blocked_policy and no work item is created.

App-level routing

Providers that use a single app-level webhook (Slack and Linear) embed a workspace identifier in every payload. Flezise resolves the connection from that identifier:

ProviderPayload field
Slackteam_id
LinearorganizationId

One workspace can connect to multiple Flezise projects. When it does, the delivery is verified and dispatched independently to each matching connection.

Next steps