The following script will start the scan for your project and periodically poll the status of the scan. When the scan is finished, the report will be downloaded to the file report.xml.
For the examples below, assume that you have stored this file as
./start_crashtest.sh#!/usr/bin/env sh
# TODO: Set WEBHOOK to webhook ID (without URL)
WEBHOOK="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"
API_ENDPOINT="https://api.crashtest.cloud/webhook"
# Start Scan and get scan ID
SCAN_ID=`curl --silent -X POST --data "" $API_ENDPOINT/$WEBHOOK | jq .data.scanId`
echo "Started Scan for Webhook $WEBHOOK. Scan ID is $SCAN_ID."
# Refresh Scan status
STATUS="100"
while [[ $STATUS -le "101" ]]
do
echo "Scan Status currently is $STATUS (101 = Running)"
# Only poll every minute
sleep 60
# Refresh status
STATUS=`curl --silent $API_ENDPOINT/$WEBHOOK/scans/$SCAN_ID/status | jq .data.status.status_code`
done
echo "Scan finished with status $STATUS."
# Download Report
curl --silent $API_ENDPOINT/$WEBHOOK/scans/$SCAN_ID/report/junit -o report.xml
echo "Downloaded Report to report.xml"Please see this article for other webhook functionalities (i.e., configuring authentication).
What is a webhook?
A webhook is a type of API that enables applications to communicate with each other over the Internet. However, unlike traditional APIs, webhooks do not require developers to make a separate call to initiate communication. Instead, webhooks allow programs to exchange information automatically based on a trigger event.
Webhooks originated as a way for GitHub to notify third-party apps about changes in repository activity. For example, when someone pushes code into a repository, GitHub sends a webhook to the app. This lets the developer know something important happened within the repository, such as a commit being pushed to the main branch.
The concept behind webhooks is similar to a reverse API, where a client initiates a request to a server. In contrast to a standard API, webhooks enable servers to push messages to clients rather than vice versa.
How to use webhooks?
Webhooks are one of those things that seem like magic to people who aren’t familiar with them. But once you learn about them, you’ll realize they’re pretty simple. You probably already know some of them. For example, when someone signs up for your email list, you send them an email saying, “Hey, I’m sending you something!” And that’s a webhook.
You’ve probably seen webhooks used in marketing emails where you sign up for a newsletter or opt-in for a freebie. When someone subscribes to your mailing list, you send them a notification letting them know that you sent them something. That’s a webhook. If you want to build a mobile app that enables you to track your customers’ location, you could set up a webhook to let you know whenever they enter a particular area. That’s another webhook.
In short, webhooks are events triggered by actions that happen on your site. They allow developers to connect applications without having to write code. There are many different types of webhooks, including ones that tell you when a specific action happens, such as when someone adds a product to their cart; others that notify you when a person changes information on a form, such as when someone enters their name or address; and still others that trigger an action when a change occurs, such as when someone submits a comment.
The most important thing to remember about webhooks is event-based notifications. This means they’re usually asynchronous, meaning they won’t block the main thread of execution while waiting for the response to come back. As a result, you can process them immediately after receiving them.
When you receive a webhook, there are three common ways to respond to it:
1. Send a reply directly to the sender of the webhook
2. Log the event and send a reply later
