Generic Webhook Integration

HookNexus is not tied to a single vendor. If a system can send an HTTP request to a URL, you can capture it—REST callbacks, internal services, IoT bridges, or bespoke integrations.

What “generic” means here

• One URL per endpoint: https://api.hooknexus.com/h/{endpoint-id}
• Any method: GET, POST, PUT, PATCH, DELETE, HEAD
• Any common body: JSON, form data, XML, plain text, or opaque binary (display may vary by type)

Step-by-step setup

1. Create an endpoint in HookNexus

   In the dashboard, create a new endpoint and copy its full URL including the path /h/....

2. Configure the sending service

   In that service’s UI or config, set the webhook URL, callback URL, or HTTP notification URL to your HookNexus URL. If the service asks for a path only, use the full URL anyway—most products accept a complete HTTPS URL.

3. Choose method and headers

   Prefer POST with Content-Type set to what you actually send (application/json, application/x-www-form-urlencoded, etc.).

4. Trigger an event

   Perform whatever action causes the remote system to call the URL (place an order, push a commit, click “Test” if available).

5. Inspect in HookNexus

   Open the request in the dashboard: method, query string, headers, and body are stored for review. On Plus, use log export to save copies you need outside HookNexus.

Testing with HTTP clients

cURL

curl -X POST "https://api.hooknexus.com/h/YOUR_ENDPOINT_ID" \
  -H "Content-Type: application/json" \
  -H "X-Custom-Header: demo" \
  -d '{"message":"hello","value":42}'

HTTPie

http POST https://api.hooknexus.com/h/YOUR_ENDPOINT_ID \
  Content-Type:application/json \
  X-Custom-Header:demo \
  message=hello value:=42

Postman

1. Create a new request, method POST, URL your HookNexus URL.
2. Headers: add Content-Type: application/json (or your type).
3. Body → raw → paste JSON or text.
4. Send and refresh HookNexus to see the capture.

Tip

Add a distinctive header (e.g. X-Debug-Source: postman) so you can tell your manual tests apart from real provider traffic.

Custom headers and content types

Scenario	Suggestion
JSON APIs	Content-Type: application/json; send UTF-8 JSON body
HTML form	application/x-www-form-urlencoded or multipart/form-data
XML	application/xml or text/xml
Arbitrary binary	Send as raw body; HookNexus stores and displays according to type

HookNexus preserves headers for inspection. For authentication headers (Authorization, custom API keys), treat HookNexus like any observer: only point non-production secrets at shared debugging tools, or use dedicated test endpoints.

Services without a webhook UI

1. Use a server or script you control

   If the “sender” is only code (e.g. another microservice), call HookNexus directly from that code using fetch, curl, or your HTTP library.

2. Use a bridge

   For databases or queues, a tiny cron job or worker can read rows and POST to HookNexus for debugging.

3. Automate with your own scripts

   From any environment, call your HookNexus URL with fetch, curl, or your HTTP library—no extra tooling required.

Caution

Do not send production passwords, full payment data, or personal data you are not allowed to log. Use synthetic payloads when possible.

Quick checklist

• URL uses HTTPS and matches your endpoint ID exactly
• Content-Type matches the body you send
• Firewall or VPN allows outbound HTTPS from the sender to api.hooknexus.com
• You can reproduce with cURL to isolate provider vs network issues

Related guides

• Receiving Webhook Requests — How HookNexus stores and displays traffic
• Signature Verification — When the provider signs payloads
• API Keys — Authenticating to HookNexus APIs (separate from webhook URL access)