Test a Webhook

Before you get started

You'll need to have your Access Token, an Event Type that you'd like to send a test payload for (refer to possible event types in Test a Webhook API reference), and a Product ID ready.

You'll also need an existing webhook to test. If you haven't yet created your first webhook, check out the Create or Update a Webhook page for more information on how to get started.

Test a Webhook

Option 1: Test a configured webhook

1. Send a POST request to https://api.tackle.io/v1/webhooks/test following the Test a Webhook API Reference:

curl -L -X POST 'https://api.tackle.io/v1/webhooks/test' \
-H 'Authorization: Bearer your-jwt-here' \
-H 'Content-Type: application/json' \
--data-raw '{  
   "productid": "{productid}",
   "event_type": "{event_type}",
}'

• {productid} is the product ID of the product you want to send a test webhook for. This is required for both Product-level and Vendor-level webhooks (Vendor-level will only be used as a fallback when Product-level webhook is not configured).
• {event_type} is the type of event to send a test payload for

2. If successful, you will receive a 200 OK response similar to the following:

{
    "data": {
        "success": true,
        "url": "{webhook_url}",
        "auth_type": "header_api_key",
        "info": [
            "Using product callback url: {webhook_url}"
        ],
        "request": {
            "body": "{request_body}"
        },
        "response": {
            "status_code": 200,
            "error": null,
            "body": "{response_body}"
        }
    },
    "metadata": {
        "link": "https://api.tackle.io/v1/webhooks/test"
    }
}

• auth_type represents the authentication method configured for your webhook
• {webhook_url} will be the URL of the webhook that the test payload was sent to
• the info key will have a log of helpful information generated during the test
• {request_body} is the payload sent to the webhook URL
• {response_body} is the response payload captured from the webhook URL

Option 2: Test a configured webhook with an overridden URL

You can use the forward_to_url to specify an alternative endpoint to send the test payload to (useful for dev/staging environments before deploying a change to production).

📘

Notes on "forward_to_url"

This works very similarly to Option 1, but with the added {forward_to_url} that will override the webhook URL found in either the product or falling back to the vendor-level webhook (if configured). This will forward the test request to the specified forward_to_url.

The authentication method configured on your original webhook URL will also be used for the forward_to_url. This means that if you used basic authentication for your registered URL, the same username and password would be passed to the forward_to_url.

1. Send a POST request to https://api.tackle.io/v1/webhooks/test with the following body:

curl -L -X POST 'https://api.tackle.io/v1/authenticate' \
-H 'Authorization: Bearer your-jwt-here' \
-H 'Content-Type: application/json' \
--data-raw '{  
   "productid": "{productid}",
   "event_type": "{event_type}",
   "forward_to_url": "{forward_to_url}" 
}'

2. If successful, you will receive a 200 OK response similar to the following:

{
    "data": {
        "success": true,
        "url": "{forward_to_url}",
        "auth_type": "header_api_key",
        "info": [
            "Using product webhook url: {webhook_url}",
            "Overwriting url with forward_to_url: {forward_to_url} "
        ],
        "request": {
            "body": "{request_body}"
        },
        "response": {
            "status_code": 200,
            "error": null,
            "body": "{response_body}"
        }
    },
    "metadata": {
        "link": "https://api.tackle.io/v1/webhooks/test"
    }
}

You'll be able to find more examples of different possible responses in the Test a Webhook API reference.