Webhook.site vs HTTPBin vs Mockbin: Best Self-Hosted Webhook Testing Tools 2026

When building integrations, APIs, or webhook-driven workflows, one of the most common challenges is debugging incoming HTTP requests. You need to see exactly what payload was sent, which headers were included, and how the request body is structured. Commercial services like webhook.site and RequestBin are convenient, but they come with limitations — rate limits, data retention policies, and the fact that your test data passes through third-party servers.

Self-hosted alternatives give you full control, unlimited request logging, and the ability to test in isolated environments. In this guide, we compare three popular open-source tools for webhook testing and HTTP inspection: Webhook.site, HTTPBin, and Mockbin — each serving a different but complementary role in the developer toolkit.

Why Self-Host Your Webhook Testing Tools

Running webhook inspection tools on your own infrastructure offers several advantages over cloud-based alternatives:

• Data privacy: Webhook payloads often contain sensitive data — user information, payment details, or internal system states. Self-hosting keeps this data within your network.
• No rate limits: Cloud services typically cap the number of requests per minute or per day. Self-hosted tools have no artificial limits.
• Persistent storage: Your request logs stay available as long as you need them, with no automatic expiration.
• Offline testing: Test webhooks without an internet connection, useful for development environments and air-gapped systems.
• Custom integrations: Hook self-hosted tools into your CI/CD pipeline, reverse proxy, or internal monitoring stack.

For teams already running Docker infrastructure, deploying these tools takes minutes. Below, we break down each option with real Docker Compose configurations fetched from their official repositories. If you’re also managing webhook delivery pipelines, check out our complete guide to self-hosted webhook management platforms and our webhook relay and tunnel setup guide for complementary tools.

Webhook.site — Real-Time Webhook Inspection

Webhook.site is the most feature-rich self-hosted webhook testing platform. It generates unique URLs that capture incoming HTTP requests and display them in real-time through a web interface, with support for WebSocket-based live updates.

GitHub Stats: 6,531 stars · Last updated: April 20, 2026 · Language: JavaScript (PHP/Laravel backend)

Key Features

• Unique webhook URLs generated on demand
• Real-time request display via WebSocket (Laravel Echo)
• Request body inspection with syntax highlighting
• Custom response configuration (status codes, headers, body)
• Redis-backed queue for handling high-volume request logging
• CORS support for cross-origin testing
• Request forwarding rules

Docker Compose Deployment

The official docker-compose.yml from the webhooksite/webhook.site repository (master branch) deploys three services: the main webhook application, a Redis instance for queue management, and a Laravel Echo Server for real-time updates.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

services:
  webhook:
    container_name: "webhook-site"
    image: "webhooksite/webhook.site"
    command: php artisan queue:work --daemon --tries=3 --timeout=10
    ports:
      - "8084:80"
    environment:
      - APP_ENV=dev
      - APP_DEBUG=false
      - APP_URL=http://localhost:8084
      - APP_LOG=errorlog
      - DB_CONNECTION=sqlite
      - REDIS_HOST=redis
      - BROADCAST_DRIVER=redis
      - CACHE_DRIVER=redis
      - QUEUE_DRIVER=redis
      - ECHO_HOST_MODE=path
    depends_on:
      - redis

  redis:
    container_name: "webhook-redis"
    image: "redis:alpine"

  laravel-echo-server:
    container_name: "laravel-echo-server"
    image: "webhooksite/laravel-echo-server"
    command:
      - exec
      - laravel-echo-server
      - start
      - --force
    environment:
      - LARAVEL_ECHO_SERVER_AUTH_HOST=http://webhook
      - LARAVEL_ECHO_SERVER_HOST=0.0.0.0
      - LARAVEL_ECHO_SERVER_PORT=6001
      - ECHO_REDIS_PORT=6379
      - ECHO_REDIS_HOSTNAME=redis
      - ECHO_PROTOCOL=http
      - ECHO_ALLOW_CORS=true
      - ECHO_ALLOW_ORIGIN=*
      - ECHO_ALLOW_METHODS=*
      - ECHO_ALLOW_HEADERS=*

Deploy with:

1
2
3

mkdir -p ~/webhook-site && cd ~/webhook-site
curl -sL https://raw.githubusercontent.com/webhooksite/webhook.site/master/docker-compose.yml -o docker-compose.yml
docker compose up -d

The web interface will be available at http://localhost:8084. Each new tab generates a unique webhook URL like http://localhost:8084/token-abc123.

Custom Response Configuration

Webhook.site lets you define custom responses for testing how clients handle different HTTP responses:

1
2
3
4
5
6
7
8

# Configure a custom JSON response
curl -X PUT http://localhost:8084/token-abc123/response \
  -H "Content-Type: application/json" \
  -d '{
    "status": 200,
    "headers": {"Content-Type": "application/json"},
    "body": "{\"message\": \"webhook received\"}"
  }'

Nginx Reverse Proxy Configuration

For production deployment, place Webhook.site behind Nginx:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

server {
    listen 80;
    server_name webhooks.example.com;

    location / {
        proxy_pass http://127.0.0.1:8084;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # WebSocket support for real-time updates
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

HTTPBin — The Standard HTTP Request/Response Service

HTTPBin by Kenneth Reitz (now maintained by Postman) is the de facto standard HTTP testing service. It provides a predictable set of endpoints for testing HTTP clients, libraries, and integrations. Unlike Webhook.site, which is designed to receive and display arbitrary incoming requests, HTTPBin offers structured endpoints for testing specific HTTP behaviors.

GitHub Stats: 13,546 stars · Last updated: May 24, 2024 · Language: Python (Flask + Gunicorn)

Key Features

• Endpoints for every HTTP method: GET, POST, PUT, DELETE, PATCH
• Response inspection: /headers, /ip, /user-agent, /cookies
• Status code testing: /status/200, /status/404, /status/500
• Response format testing: /json, /xml, /html, /image/png
• Authentication testing: /basic-auth, /digest-auth, /bearer
• Redirect testing: /redirect/3, /relative-redirect/2
• Response delay simulation: /delay/5 (adds N-second delay)
• Base64 encoding/decoding: /base64/{value}
• Gzip and deflate compression responses

Docker Compose Deployment

The official docker-compose.yml from postmanlabs/httpbin is simple — a single service:

1
2
3
4
5
6

version: '2'
services:
    httpbin:
      build: '.'
      ports:
        - '80:80'

For a production-ready deployment using the pre-built Docker image:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

services:
  httpbin:
    image: "kennethreitz/httpbin:latest"
    container_name: "httpbin"
    ports:
      - "8080:80"
    restart: unless-stopped
    deploy:
      resources:
        limits:
          memory: 256M

Deploy with:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

mkdir -p ~/httpbin && cd ~/httpbin
cat > docker-compose.yml << 'EOF'
services:
  httpbin:
    image: "kennethreitz/httpbin:latest"
    container_name: "httpbin"
    ports:
      - "8080:80"
    restart: unless-stopped
EOF
docker compose up -d

Practical Usage Examples

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

# Test a POST request with JSON body
curl -X POST http://localhost:8080/post \
  -H "Content-Type: application/json" \
  -d '{"key": "value", "test": true}'

# Inspect your request headers
curl http://localhost:8080/headers

# Test authentication
curl -u user:pass http://localhost:8080/basic-auth/user/pass

# Test redirect behavior
curl -v http://localhost:8080/redirect/3

# Simulate a slow response (5 second delay)
curl http://localhost:8080/delay/5

# Get a specific HTTP status code
curl -I http://localhost:8080/status/418

Caddy Reverse Proxy Configuration

1
2
3
4
5
6

httpbin.example.com {
    reverse_proxy localhost:8080

    # Automatic HTTPS with Let's Encrypt
    tls admin@example.com
}

Mockbin — API Mocking and Request Recording

Mockbin, originally built by Mashape and now maintained by Kong (the company behind Kong Gateway and Insomnia), is a powerful tool for creating mock API endpoints. Unlike Webhook.site (which passively receives requests) and HTTPBin (which provides fixed testing endpoints), Mockbin lets you define custom mock endpoints that return specific responses — making it ideal for API development and integration testing.

GitHub Stats: 2,046 stars · Last updated: April 23, 2026 · Language: JavaScript (Node.js)

Key Features

• Create custom mock endpoints with defined request/response pairs
• Record real API traffic and replay it as mock responses
• Dynamic response generation with templating
• Request matching by method, path, headers, and body
• CORS support for frontend testing
• Redis-backed storage for mock configurations
• Programmatic API for creating and managing mocks
• Integration with Insomnia API client

Docker Compose Deployment

The official docker-compose.yml from Kong/insomnia-mockbin (master branch) uses a two-service architecture with Redis for mock storage:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

services:
  app:
    build: .
    environment:
      MOCKBIN_REDIS: "redis://redis:6379"
      MOCKBIN_QUIET: "false"
      MOCKBIN_PORT: "8080"
      MOCKBIN_REDIS_EXPIRE_SECONDS: 1000000000
    links:
      - redis
    ports:
      - "8080:8080"

  redis:
    image: redis

For production deployment with the pre-built image:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

services:
  mockbin:
    image: "mashape/mockbin:latest"
    container_name: "mockbin"
    environment:
      MOCKBIN_REDIS: "redis://redis:6379"
      MOCKBIN_QUIET: "false"
      MOCKBIN_PORT: "8080"
      MOCKBIN_REDIS_EXPIRE_SECONDS: 604800
    ports:
      - "8081:8080"
    depends_on:
      - redis
    restart: unless-stopped

  redis:
    image: "redis:alpine"
    container_name: "mockbin-redis"
    command: redis-server --appendonly yes
    volumes:
      - mockbin-redis-data:/data

volumes:
  mockbin-redis-data:

Deploy with:

1
2

mkdir -p ~/mockbin && cd ~/mockbin
docker compose up -d

Creating Mock Endpoints via API

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

# Create a new mock endpoint
curl -X POST http://localhost:8081/mock \
  -H "Content-Type: application/json" \
  -d '{
    "name": "test-api",
    "response": {
      "status": 200,
      "headers": {
        "Content-Type": "application/json"
      },
      "body": "{\"status\": \"ok\", \"data\": {\"id\": 1}}"
    }
  }'

# Access the mock endpoint
curl http://localhost:8081/view/test-api

Feature Comparison Table

Which Tool Should You Choose?

Choose Webhook.site when:

• You need to inspect incoming webhook payloads in real-time
• You want a visual interface showing request details live
• You’re debugging third-party integrations (Stripe, GitHub, Slack webhooks)
• You need unique URLs for each test session
• Your team needs collaborative access to webhook logs

Choose HTTPBin when:

• You’re testing HTTP client libraries or SDKs
• You need predictable endpoints for automated testing
• You want to simulate specific HTTP behaviors (redirects, auth, delays)
• You need a lightweight, single-container deployment
• You’re building integration tests in CI/CD pipelines

Choose Mockbin when:

• You need to create mock API endpoints for frontend development
• You want to record and replay real API responses
• You’re building against an API that isn’t ready yet
• You need programmatic control over mock responses
• You’re already using the Insomnia API client ecosystem

Combining All Three Tools

For comprehensive API development and testing, consider deploying all three tools side by side:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

services:
  webhook-site:
    image: "webhooksite/webhook.site"
    ports:
      - "8084:80"
    environment:
      - APP_ENV=production
      - APP_URL=http://localhost:8084
      - DB_CONNECTION=sqlite
      - REDIS_HOST=webhook-redis
      - BROADCAST_DRIVER=redis
      - CACHE_DRIVER=redis
      - QUEUE_DRIVER=redis
    depends_on:
      - webhook-redis

  webhook-redis:
    image: "redis:alpine"

  httpbin:
    image: "kennethreitz/httpbin:latest"
    ports:
      - "8080:80"

  mockbin:
    image: "mashape/mockbin:latest"
    ports:
      - "8081:8080"
    environment:
      MOCKBIN_REDIS: "redis://mockbin-redis:6379"
      MOCKBIN_PORT: "8080"
    depends_on:
      - mockbin-redis

  mockbin-redis:
    image: "redis:alpine"

This gives you webhook inspection on port 8084, HTTP testing on port 8080, and API mocking on port 8081 — all running locally with a single docker compose up -d command.

FAQ

What is the difference between Webhook.site and HTTPBin?

Webhook.site is designed for receiving and inspecting arbitrary incoming HTTP requests — it generates unique URLs and displays the request payload, headers, and metadata in a real-time web interface. HTTPBin, on the other hand, provides a fixed set of predefined endpoints for testing HTTP client behavior (authentication, redirects, status codes, response formats). They serve complementary purposes: Webhook.site is for debugging what you receive, HTTPBin is for testing what you send.

Can I use these tools behind a reverse proxy?

Yes, all three tools work well behind reverse proxies. Webhook.site requires additional WebSocket configuration in your proxy (Nginx or Caddy) to support real-time updates. HTTPBin and Mockbin are standard HTTP services that work with any reverse proxy out of the box. For production use, always enable TLS termination at the proxy level. For a deeper dive into reverse proxy configurations, see our load balancer comparison guide which covers Nginx, HAProxy, and Traefik setups.

Do these tools store request data permanently?

Webhook.site stores all incoming requests in its SQLite database (or Redis queue) until you clear them. HTTPBin does not store any data — it processes requests in memory and returns the response immediately. Mockbin stores mock endpoint definitions in Redis but does not log incoming requests by default. For persistent request logging with Webhook.site, ensure the SQLite database file is mounted as a Docker volume.

Which tool is best for CI/CD pipeline testing?

HTTPBin is the most suitable for CI/CD pipelines due to its lightweight single-container deployment and predictable, stateless endpoints. You can spin it up in a CI job, run your integration tests against it, and tear it down without any cleanup. Webhook.site and Mockbin require Redis dependencies and maintain state, making them better suited for longer-running development or staging environments.

How do I secure a self-hosted webhook testing instance?

For production deployments: (1) Always use TLS via a reverse proxy with Let’s Encrypt certificates, (2) Restrict access with IP allowlists or basic authentication at the proxy level, (3) For Webhook.site, set APP_DEBUG=false in production, (4) Consider adding rate limiting at the reverse proxy to prevent abuse, (5) Regularly rotate or regenerate webhook URLs if they are exposed publicly.

Can these tools handle high-throughput webhook traffic?

Webhook.site is designed for higher throughput with its Redis-backed queue architecture, capable of handling hundreds of requests per second with proper Redis configuration. HTTPBin is single-process (Gunicorn with gevent workers) and better suited for moderate testing loads. Mockbin’s performance depends on Redis configuration — with Redis persistence enabled, it can handle sustained traffic. For production webhook processing at scale, consider dedicated message queue solutions alongside these inspection tools.