How to connect WordPress with webhooks

Decide whether WordPress will send data to another service, receive data from another service, or do both. Write down the event, the HTTP method, the payload fields, the expected response, and what should happen if the request fails.

Use HTTPS for both sides. Treat webhook URLs, bearer tokens, and signing secrets as credentials, not as ordinary settings that can be exposed in page content.

For incoming webhooks, create a small plugin or site-specific integration that registers a custom REST API route. WordPress requires custom routes to be registered through register_rest_route() on the rest_api_init hook, and the route can accept a POST request handled by your callback.

Read the request body in the callback, validate the content type and required fields, then check a shared secret or signature before changing anything in WordPress. Do not use a browser nonce as the authentication method for a third-party server calling your endpoint; WordPress documents nonces primarily for requests made by logged-in users in the site context.

For outgoing webhooks, call the receiving service with WordPress's HTTP API. The usual function for a JSON POST is wp_remote_post(); pass the destination URL, JSON body, content type, authentication header, and a sensible timeout. The function returns either a response array or WP_Error, so handle both outcomes.

Trigger the request from the event you care about, such as a form submission, a published post, or an order status change. Keep the webhook code in a small custom plugin or site-specific plugin rather than the active theme, so a theme change does not remove the integration.

Use the authentication method required by the receiving service, commonly a bearer token, basic authentication, or a signature calculated from the raw request body. Store secrets outside templates and never print them in logs or return them in the response. Validate incoming fields, reject unexpected methods, and check permissions before creating or updating WordPress data.

A public endpoint can attract repeated or forged requests. Add rate limiting or upstream protection where appropriate, and make the handler idempotent by recording an event ID or rejecting duplicates. A successful HTTP response should mean the request was accepted, not that every downstream action has completed.

Send a test request with the exact method, headers, and JSON structure expected by the other service. Confirm the receiving endpoint returns the expected status code and that WordPress or the external app performs only one action.

When an integration fails, inspect the HTTP status, response body, server error log, and webhook delivery log. A 401 usually points to missing or incorrect authentication, a 403 often indicates a firewall, security plugin, or permission rule, and a timeout can indicate DNS, TLS, hosting, or a slow callback.

For a small, stable integration, the manual route is fine and gives you full control. It becomes costly when you need several WordPress events, incoming and outgoing connections, field mapping, delivery logs, retries, or integrations that non-developers must maintain.

For the faster route, use AutomatorWP with its Webhooks extension. It provides two-way webhook triggers and actions for connecting WordPress to APIs and external apps through configured workflows, so you can avoid maintaining a separate custom integration for each connection.