Requex.me LogoRequex.me

Documentation

Browse by section

Keep all guides, tool docs, automation recipes, and comparison pages in one navigable place.

Docs Home
Docs

Foundation docs for getting started fast, understanding key terms, and tracking what has changed.

Guides

Start with fundamentals, then move into provider-specific webhook testing and production hardening.

Tool Docs

These pages explain what each tool does, when to use it, and how it fits into a webhook debugging workflow.

Automation Docs

Use these setup guides when you want forwarding rules, custom responses, security checks, or multi-destination fanout.

Compare

Use these pages to compare developer workflows, pricing tradeoffs, and feature differences between webhook tools.

Webhook Testing in CI/CD Pipelines

Run automated webhook tests in GitHub Actions, GitLab CI, and other pipelines using Requex as a controllable mock endpoint.

Editorially reviewed by the Requex team•9 min read•About the product

Quick Answer

The core problem with webhook testing in CI is that your pipeline runners don't have a persistent public URL. Use a pre-created Requex endpoint as a stable mock target in your pipeline — send test events to it with curl, then verify delivery via the Requex API or simply confirm the curl exits 200.

The Problem with Webhooks in CI/CD

Automated webhook integration tests have a fundamental challenge: they need a real public HTTPS endpoint that can receive HTTP requests from your webhook source. CI pipeline runners — GitHub Actions workers, GitLab CI runners, Jenkins agents — are ephemeral. They don't have public IPs, they run behind NAT, and they're torn down after each job.

The common workarounds are messy. Running a temporary server with ngrok in your pipeline introduces installation complexity, auth tokens, and non-deterministic subdomain URLs. Mocking the HTTP client entirely misses integration-level issues — your application's actual HTTP sending code never runs.

Requex solves this by providing a stable, persistent HTTPS endpoint that you can create once and reference permanently in your pipeline configuration — no tunnel, no installation, no dynamic URL management.

Two Patterns for CI Webhook Testing

Pattern 1 — Outbound delivery test

Your application sends webhooks to external services. In tests, swap the destination URL with your Requex endpoint and verify that your application sends the correct payload, headers, and signature.

Example: You build a SaaS platform that sends order events to customer webhook URLs. In CI, substitute the customer URL with Requex and assert the payload schema matches your contract.

Pattern 2 — Inbound handler test

Your application receives webhooks from external services. In CI, use Requex's response simulation to return controlled status codes and test your retry logic, error handling, and idempotency.

Example: Configure Requex to return 500 and verify your application retries with exponential backoff before giving up.

GitHub Actions Example

Store your Requex webhook ID as a GitHub Actions secret (REQUEX_WEBHOOK_ID), then use curl in your workflow to send a test event and verify the 200 response:

name: Webhook Integration Test

on: [push, pull_request]

jobs:
  test-webhook-delivery:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Run application tests
        run: npm test

      - name: Test webhook delivery
        env:
          REQUEX_WEBHOOK_ID: ${{ secrets.REQUEX_WEBHOOK_ID }}
        run: |
          # Send test payload to Requex mock endpoint
          HTTP_STATUS=$(curl -s -o /dev/null -w "%{http_code}" \
            -X POST \
            "https://requex.me/hook/${REQUEX_WEBHOOK_ID}" \
            -H "Content-Type: application/json" \
            -H "X-Webhook-Secret: test-secret" \
            -d '{
              "event": "order.created",
              "data": {
                "order_id": "test-001",
                "amount": 9900,
                "currency": "usd"
              }
            }')

          echo "Response status: $HTTP_STATUS"

          if [ "$HTTP_STATUS" != "200" ]; then
            echo "Webhook delivery failed with status $HTTP_STATUS"
            exit 1
          fi

          echo "Webhook delivery test passed"

Testing Retry Logic with Response Simulation

Requex's response configuration lets you set a specific status code for all incoming requests. This is powerful for testing how your application handles webhook delivery failures.

For example, to test your application's retry behaviour when a downstream webhook endpoint is unavailable:

  1. Create a dedicated Requex endpoint for failure simulation tests.
  2. Configure it to return 500 in the Settings tab.
  3. Point your application at it and trigger a webhook delivery.
  4. Verify that your application retries the delivery the expected number of times with the correct backoff interval.
  5. Change the response to 200 and verify the retry queue clears.

GitLab CI Example

The same pattern works in GitLab CI. Store the webhook ID as a CI/CD variable and use it in your test stage:

webhook-integration-test:
  stage: test
  script:
    - |
      HTTP_STATUS=$(curl -s -o /dev/null -w "%{http_code}" \
        -X POST \
        "https://requex.me/hook/${REQUEX_WEBHOOK_ID}" \
        -H "Content-Type: application/json" \
        -d '{"event":"test","timestamp":"'"$(date -u +%Y-%m-%dT%H:%M:%SZ)"'"}')
      test "$HTTP_STATUS" = "200"
  variables:
    REQUEX_WEBHOOK_ID: $REQUEX_WEBHOOK_ID

Best Practices

  • →Use a dedicated Requex endpoint for CI tests — don't share with manual debugging sessions to avoid noise.
  • →Store the webhook ID as a secret, not hardcoded, so you can rotate it without code changes.
  • →For outbound tests, validate the payload schema in the test — not just that curl returned 200.
  • →Use Requex's forwarding rules in staging environments to route to your actual handler alongside the inspection endpoint.

Related Resources

Start Testing Webhooks Now

Generate your unique URL and test webhooks instantly. Free, no signup.

Open Webhook Tester →