GitLab
Receive GitLab merge request and pipeline events in Wexio flows
Wexio compares the X-Gitlab-Token header with your secret token. GitLab sends the token as-is and does not sign the body, so this mode checks who sent the request but not that the body is unchanged, and it has no replay protection. Inbound webhooks need the Pro or Enterprise plan.
Provider docs: Webhooks in GitLab
Setup
1. Connect It in Wexio
Go to Settings → Webhooks and API → Webhooks → New connection → Inbound and click the GitLab chip under Dedicated providers, or set Authentication mode to GitLab (secret token) manually. Copy the Wexio endpoint URL.
2. Set Up the Provider
In GitLab, open your project or group, then Settings → Webhooks, and add the Wexio endpoint URL as the URL. Pick the triggers you need.
You choose the secret token yourself. Enter any strong value in the GitLab Secret token field, then paste the same value into the Wexio Signing secret field.
Send X-Idempotency-Key where you can. Use HTTPS only, because the token travels in a header.
3. Resolve Contacts
Pick the field in the GitLab payload that matches a Wexio contact, for example $.user_email. Many events carry none, so you may need a fixed Chat ID. Capture a sample event to see the payload shape, as described in Inbound Webhooks.
4. Bind a Flow
Attach a Webhook Received trigger to the connection and branch on the event type field in the payload.
Check That It Works
Trigger a GitLab event, then open Webhook History. A request that passed verification is listed as received. A failed one shows its error.
Troubleshooting
| Symptom | Fix |
|---|---|
UNAUTHORIZED: GitLab token mismatch | The token in GitLab and the Signing secret in Wexio differ. Make them the same string |
UNAUTHORIZED: Missing X-Gitlab-Token header | The GitLab webhook has no Secret token, or a proxy removed the header |
Related
- Inbound Webhooks - auth modes, contact resolution and response codes
- Webhook Received - the trigger that starts your flow
- Webhook History - check why a request failed