Nango vs Hook0 vs Convoy: Self-Hosted API Integration and Webhook Delivery Guide 2026

When your application needs to connect to third-party APIs or deliver webhook events to downstream consumers, you face two distinct but related challenges: managing OAuth credentials and API tokens for outbound integrations, and reliably delivering webhook events to subscribers. Nango solves the first problem with a unified integration platform. Hook0 and Convoy solve the second with purpose-built webhook delivery engines.

In this guide, we compare all three tools so you can build reliable, self-hosted API integrations and webhook delivery pipelines.

Quick Comparison

Nango: Unified API Integration Platform

Nango is an open-source integration platform that provides pre-built connectors for 250+ APIs (Salesforce, HubSpot, Slack, GitHub, Stripe, and many more). Instead of building and maintaining OAuth flows, token refresh logic, and API wrapper code for each third-party service, Nango handles all of this behind a unified interface.

Docker Deployment

 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

services:
  nango:
    image: nangohq/nango-server:latest
    ports:
      - "3003:3003"
    environment:
      - NANGO_DB_HOST=postgres
      - NANGO_DB_NAME=nango
      - NANGO_DB_USER=nango
      - NANGO_DB_PASSWORD=nango_password
      - NANGO_ENCRYPTION_KEY=your-32-character-encryption-key
    depends_on:
      - postgres

  postgres:
    image: postgres:16-alpine
    environment:
      POSTGRES_USER: nango
      POSTGRES_PASSWORD: nango_password
      POSTGRES_DB: nango
    volumes:
      - nango_data:/var/lib/postgresql/data

  jobs:
    image: nangohq/nango-jobs:latest
    environment:
      - NANGO_DB_HOST=postgres
      - NANGO_REDIS_HOST=redis

  redis:
    image: redis:7-alpine

volumes:
  nango_data:

Using Nango to Connect to a Third-Party API

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

# 1. Create an integration (e.g., GitHub)
curl -X POST http://localhost:3003/config \
  -H "Content-Type: application/json" \
  -d '{
    "provider_config_key": "github",
    "provider": "github",
    "oauth_client_id": "your-github-client-id",
    "oauth_client_secret": "your-github-client-secret"
  }'

# 2. Initiate OAuth flow (redirects user to GitHub)
# Your app redirects the user to:
# http://localhost:3003/oauth/connect/github?connect_session_token=SESSION_TOKEN

# 3. After authorization, get the access token
curl -X GET http://localhost:3003/connection/github \
  -H "Authorization: Bearer YOUR_SECRET_KEY"

Sync Data from a Third-Party API

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

import { Nango } from "@nangohq/node";

const nango = new Nango({ secretKey: "YOUR_SECRET_KEY" });

// Sync GitHub issues into your database
const connections = await nango.listConnections("github");
for (const conn of connections) {
  const issues = await nango.proxy({
    method: "GET",
    endpoint: "/repos/owner/repo/issues",
    providerConfigKey: "github",
    connectionId: conn.connection_id,
  });
  
  // Process the issues in your application
  await storeIssues(issues.data);
}

Key Features

• 250+ pre-built connectors — GitHub, Slack, Salesforce, HubSpot, Jira, Stripe, Google Workspace, and more
• OAuth lifecycle management — handles authorization, token refresh, and re-authorization automatically
• Unified API — one SDK for all integrations, regardless of the underlying provider
• Sync engine — pull data from third-party APIs on a schedule with incremental sync support
• Proxy layer — make API calls through Nango’s proxy to handle authentication transparently
• Webhook ingestion — receive webhooks from providers and forward them to your application
• Multi-environment — separate dev, staging, and production integration configurations

When to Use Nango

Choose Nango when your application needs to integrate with many third-party APIs. It eliminates the need to build and maintain individual OAuth flows, token refresh logic, and API wrapper code for each service. If you are building a SaaS product that connects to Slack, GitHub, and Salesforce, Nango handles all three through a single interface.

Hook0: Webhook Delivery as a Service

Hook0 is a self-hosted webhook delivery platform built in Rust. It provides a reliable pipeline for sending webhook events to downstream consumers, with automatic retries, event signing, and delivery tracking.

Docker Deployment

 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

services:
  hook0:
    image: ghcr.io/hook0/hook0-server:latest
    ports:
      - "7082:7082"
    environment:
      - HOOK0_DATABASE_URL=postgresql://hook0:hook0_pass@postgres:5432/hook0
      - HOOK0_REDIS_URL=redis://redis:6379
      - HOOK0_ENCRYPTION_KEY=your-encryption-key-here
    depends_on:
      - postgres
      - redis

  postgres:
    image: postgres:16-alpine
    environment:
      POSTGRES_USER: hook0
      POSTGRES_PASSWORD: hook0_pass
      POSTGRES_DB: hook0
    volumes:
      - hook0_data:/var/lib/postgresql/data

  redis:
    image: redis:7-alpine

volumes:
  hook0_data:

Sending a Webhook Event

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

# Create a webhook subscription
curl -X POST http://localhost:7082/api/v1/subscriptions \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "order-updates",
    "url": "https://example.com/webhook/orders",
    "events": ["order.created", "order.updated"],
    "signing_secret": "whsec_your_secret"
  }'

# Send an event
curl -X POST http://localhost:7082/api/v1/events \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "event_type": "order.created",
    "payload": {
      "order_id": "ORD-12345",
      "total": 99.99,
      "currency": "USD"
    }
  }'

Key Features

• Automatic retries — configurable retry policies with exponential backoff
• Event signing — HMAC-SHA256 signatures for payload verification
• Delivery tracking — monitor delivery status, response codes, and latency per endpoint
• Rate limiting — prevent overwhelming downstream services with configurable rate limits
• Multi-tenant — isolate webhook configurations per organization or project
• REST API — manage subscriptions, events, and delivery logs programmatically
• Dashboard — visualize delivery metrics, retry queues, and endpoint health

When to Use Hook0

Choose Hook0 when you need a lightweight, purpose-built webhook delivery system. It is ideal for SaaS platforms that notify customers about events (order updates, user sign-ups, status changes) and need guaranteed delivery with retry logic and signature verification.

Convoy: Enterprise Webhook Platform

Convoy is a Go-based webhook delivery platform designed for enterprise use cases. It provides a complete webhook management system with fan-out delivery, dynamic rate limiting, and comprehensive observability.

Docker Deployment

 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

services:
  convoy:
    image: fraindev/convoy:latest
    command: ["convoy", "server"]
    ports:
      - "5001:5001"
    environment:
      - CONVORY_REDIS_DSN=redis://redis:6379
      - CONVORY_DATABASE_DSN=postgres://convoy:convoy_pass@postgres:5432/convoy?sslmode=disable
      - CONVORY_SERVER_HTTP_PORT=5001
      - CONVORY_SIGNATURE_HASH=SHA256
      - CONVORY_SIGNATURE_HEADER=X-Convoy-Signature
    depends_on:
      - postgres
      - redis

  worker:
    image: fraindev/convoy:latest
    command: ["convoy", "worker"]
    environment:
      - CONVORY_REDIS_DSN=redis://redis:6379
      - CONVORY_DATABASE_DSN=postgres://convoy:convoy_pass@postgres:5432/convoy?sslmode=disable

  postgres:
    image: postgres:16-alpine
    environment:
      POSTGRES_USER: convoy
      POSTGRES_PASSWORD: convoy_pass
      POSTGRES_DB: convoy
    volumes:
      - convoy_data:/var/lib/postgresql/data

  redis:
    image: redis:7-alpine

volumes:
  convoy_data:

Sending Events via Convoy

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

# Create an endpoint
curl -X POST http://localhost:5001/api/v1/projects/default/endpoints \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com/webhook",
    "events": ["*"],
    "description": "Main webhook endpoint",
    "secret": "convoy_webhook_secret"
  }'

# Send an event
curl -X POST http://localhost:5001/api/v1/projects/default/events \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "event_type": "payment.completed",
    "data": {
      "transaction_id": "TXN-67890",
      "amount": 150.00,
      "status": "completed"
    }
  }'

Key Features

• Fan-out delivery — deliver a single event to multiple endpoints simultaneously
• Dynamic rate limiting — per-endpoint rate limits that adapt to consumer capacity
• Event replay — replay failed or missed events to any endpoint at any time
• Webhook ingestion — receive webhooks from third-party providers and forward them internally
• Project isolation — separate webhook configurations per project or tenant
• CLI and API — manage everything via command line or REST API
• Dashboard — monitor delivery rates, failure patterns, and endpoint health

When to Use Convoy

Choose Convoy when you need enterprise-grade webhook delivery with fan-out capabilities and event replay. It is ideal for payment processors, marketplace platforms, and any system where webhook delivery reliability directly impacts revenue.

Why Self-Host Webhook Delivery?

Using a SaaS webhook service (like Svix or Hookdeck) introduces a third-party dependency into your event-driven architecture. If the webhook provider goes down, your downstream integrations break. By self-hosting, you control the delivery pipeline, keep event data within your infrastructure, and eliminate per-event pricing.

For organizations processing millions of webhook events per month, self-hosting also reduces costs significantly. SaaS webhook platforms typically charge per-event or per-delivery, which scales linearly with usage. Self-hosted tools like Hook0 and Convoy have fixed infrastructure costs regardless of volume.

For API connectivity beyond webhooks, our webhook testing guide covers tools for testing and debugging webhook endpoints. And for API gateway management, our API gateway comparison provides guidance on routing and securing API traffic.

Choosing the Right Tool

FAQ

Can Nango deliver webhooks?

Nango can receive webhooks from third-party providers (like Stripe or GitHub) and forward them to your application. However, it is not a general-purpose webhook delivery platform for your own events. For outbound webhook delivery to your customers, use Hook0 or Convoy alongside Nango.

What is the difference between Hook0 and Convoy?

Hook0 is built in Rust and focuses on being a lightweight, fast webhook delivery service with a simple API. Convoy is built in Go and provides more enterprise features like fan-out delivery, dynamic rate limiting, and event replay. For most use cases, either will work — choose Hook0 for simplicity and Convoy for advanced features.

How do webhook signatures work?

When Hook0 or Convoy delivers a webhook, they compute an HMAC-SHA256 hash of the request body using a shared secret. This hash is included in the request header (e.g., X-Hook0-Signature or X-Convoy-Signature). Your receiving application computes the same hash and compares it to verify the payload was not tampered with.

Do these tools support custom retry policies?

Yes. All three tools support configurable retry logic. Hook0 and Convoy let you set the number of retries, backoff strategy (linear or exponential), and retry intervals. Nango handles OAuth token refresh automatically, which is a different kind of retry — it retries failed API calls with refreshed credentials.

Can I migrate from a SaaS webhook provider?

Yes. Both Hook0 and Convoy support importing endpoint configurations and can replay historical events. The migration process involves exporting your endpoint URLs and secrets from the SaaS provider, importing them into your self-hosted instance, and switching your application to point to the self-hosted API endpoint.

How do these tools handle high-volume event streams?

Hook0 and Convoy both use Redis as a message queue to buffer events before delivery. This provides backpressure protection — if a downstream endpoint is slow, events queue up in Redis rather than blocking the event ingestion API. Convoy additionally supports a worker process model for horizontal scaling of delivery throughput.