How to check the webhook?

Test your webhook on the server and locally

In order to receive incoming webhooks, a public IP address / host is required to be accessible from the Internet. This way the Whapi.Cloud server will be able to make a call to your server at the specified address and deliver the incoming webhook.

Server configuration

Your endpoint needs to accept a POST/PUT/PATCH/DELETE;

The Troubleshootingsection will help you to understand frequently occurring errors.

How to test Webhook functionality?

To check and test Webhook and make sure that the server is sending data, we offer you the easiest and fastest option - Webhook simulation.

You can use our solution for this:

We will provide you with a free unique URL that will allow you to test and debug your HTTP requests.

After selecting a channel, a unique URL will be set in the channel settings. Callbacks of selected events will be sent to this URL and displayed on this page, which updates every 10 seconds. By default, the webhook mode is set to “method”; change this in the channel settings if needed. For more events, specify the additional events in the channel settings. Read more about webhook setting.

A similar solution could be similar third-party services like webhook.site:

You get a unique link;
Paste it in the channel settings;
See how notifications are caught, what format they are in. This will help to process them in the script.

How to test Webhook locally?

When developing a WhatsApp bot, you might want to test it locally before deploying it to a server.

The simplest way to do this is to use tools like Ngrok, which creates a secure tunnel to your localhost, allowing you to provide access to your local server from the internet.

Download Ngrok from the official website and extract it. Open the terminal and navigate to the folder where Ngrok is stored. Run ./ngrok http PORT_NUMBER, replacing PORT_NUMBER with the port your Express server is running on locally. Now you should have a public URL that you can use as a URL for your webhook.

Alternatives for local tunneling

Here are some good alternatives to Ngrok for tunneling callbacks to your local machine:

Localtunnel: A simple and convenient service that allows you to expose your local servers to the Internet. https://localtunnel.github.io/www/
Serveo: A free service that allows you to create a tunnel to your local server without the need to install additional tools. https://serveo.net/
Pagekite: A reliable solution for exposing local servers, supporting multiple protocols and easy to configure. https://pagekite.net/
Telebit: Secure tunneling with encryption support, suitable for safe access to local resources. https://telebit.cloud/
Beeceptor: A service for creating mock servers and tunneling, allowing you to test and debug APIs. https://beeceptor.com/
Eclipse Che: A cloud development environment that includes tunneling capabilities. https://eclipse.dev/che/

Troubleshooting

404 Not Found

Cause: The requested resource or endpoint does not exist on the server.

Solution:

Verify the URL and ensure it is correctly spelled and corresponds to the correct API endpoint.
Check that a handler for the specific path exists and is available.
Check the server code or configuration to see if a handler is registered for the URL you are trying to use.
Check the URL rewrite rules to make sure that they do not change the path so that the request goes to a non-existent handler.
Check the server's routing configurations to ensure the endpoint is defined.

404 Not Found error with Ngrok

Ensure that your local application is running and accessible on the same port you have specified in Ngrok.
Review the Ngrok logs (available in the Ngrok web interface at http://127.0.0.1:4040) to see traffic details and possible routing errors.

405 Method Not Allowed

Cause: The HTTP method used is not allowed for the requested resource.

Solution: Check the server's configurations to allow the HTTP method being used, or ensure the correct method is used for the API endpoint.

1. Configuring Apache Server

If your server runs on Apache, you can use the .htaccess file to allow or disallow specific methods. Here's how you can enable POST requests for all resources:

<Directory "/var/www/html">
    AllowOverride All
    Order allow,deny
    Allow from all
    <LimitExcept GET POST>
        Deny from all
    </LimitExcept>
</Directory>

This code configures Apache to allow GET and POST requests, denying all other types of requests.

2. Configuring NGINX

For NGINX servers, you can add or modify the existing server configuration file to allow POST methods:

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://localhost:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;

        # Allow POST
        limit_except POST {
            deny all;
        }
    }
}

This configuration solves the problem by restricting access to methods other than POST.

3. Configuring IIS (Internet Information Services)

In IIS, you can manage allowed methods via the graphical user interface or configuration files:

Open IIS Manager.
Select the site or application you want to configure.
Go to the “Handler Mappings” section.
Modify or add new mappings to allow the POST method.

4. Configuring Application Servers

For application servers such as Tomcat or Jetty, you can configure allowed methods in your application code, for example, by adding checks on the request method in your servlet or controller.

protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
    // Handling POST request
}

In this code, the servlet handles only POST requests, which prevents the 405 error for POST.

500 Internal Server Error

Cause: The server encountered an unexpected condition that prevented it from fulfilling the request.

Solution: Check server logs to diagnose the issue. It could be due to a coding error, failed dependencies, or resource limitations. Debug and fix the issue based on specific error details from the logs.

502 Bad Gateway

Cause: The server, while acting as a gateway or proxy, received an invalid response from the upstream server.

Solution: Verify the configuration and status of upstream servers. Ensure that the proxy server is correctly routing requests and that all servers in the chain are running properly.

503 Service Unavailable

Cause: The server is currently unable to handle the request due to temporary overloading or maintenance.

Solution: If it’s a temporary load issue, consider implementing load balancing or increasing server capacity. If maintenance is the cause, wait until it completes, or notify users of downtime.

525 SSL Handshake Failed

Cause: SSL handshake between the client’s server and the server it’s communicating with failed.

Solution: Check SSL certificates for validity, expiration, and proper configuration. Ensure that the server supports the cryptographic protocols used by the client.

PreviousDetailed webhook settings NextIncoming webhooks format

Last updated 3 days ago