Assertible's automation let's you integrate web application testing with the tools and service's you already use. If a critical API is down, has a slow response time, or fails any other assertions, you can set up automation and hooks to alert you or process some other action.

API testing automation with Assertible is extremely useful because of the way assertions work. You can run your web service tests continuously throughout the development cycle and get alerted early when there's problems with a release.


Assertible Slack integration


Integrations are a means to hook your test runs and results into other 3rd party services, like a team chat. Good, timely, and reliable integrations are crucial for teams sharing information.

The currently supported integrations are:

GitHub Deployments

Connecting your Assertible web service with a GitHub repository allows you to propogate deployment events and tests failures to pull requests and commit references every time you deploy.

Assertible GitHub Continuous Testing Integration

GitHub quick start

There are 2 steps required to make use of the Assertible GitHub integration:

  1. Connect your Assertible web service to GitHub

  2. Post deployments to Assertible

Connect Assertible to GitHub

Connect an Assertible web service to GitHub by navigating to your web service's Deployments tab. On the left hand sidebar, click GitHub status checks.

If you have never configured GitHub in Assertible before, you should see an Add to GitHub button that allows you to connect, as seen in the image below.

Assertible dashboard GitHub status checks deployments settings

Once you have granted Assertible the necessary GitHub permissions, you can select a repository to send/recieve deployments events from.

Assertible GitHub Continuous Testing Integration

Check out our listing in the GitHub integrations directory.

Post deployments to Assertible

In order for Assertible to run tests when your web app or API is deployed, it must receive deployment events and propogate them to your repository on GitHub.

  • Deployments API

    The easiest way to send deployment events to GitHub is to use the Assertible deployments API.

    All you have to do is connect your web service to GitHub, and call POST /deployments with the github: true parameter. See our deployments API examples for how to configure your request.

    We've put together examples for common CI/CD services in the assertible/deployments repo.

  • External integrations

    If you use an external continuous delivery service like Heroku that is already connected to your GitHub repository, you don't need to use the deployments API.

    For example, Heroku Review Apps, creates a deployment event for all apps spun up for every pull request. These events are received by Assertible which runs tests against the web app for each unique environment.

How it works

When you connect Assertible to a GitHub repository, it receives webhooks for all repository events related to deployments. Using the webhook payload, Assertible can determine when your web service has been deployed and will run tests against your app automatically.

Loading an environment

Environment "loading" is the process of identifying the unique url and other HTTP settings which are specific to an instance of your app. For example, your staging environments may all be deployed to a unique environment like https://${branch} or even a static url like

The method Assertible uses to resolve the test execution environment from a GitHub deployment event can be broken down into a few steps:

  • If the deployment event contains an environment field (the unique name of the environment), Assertible checks your environments for a corresponding unique name.

    For example, if the GitHub deployment event contains { "environment": "staging", ... } then Assertible will attempt to find a valid environment for the web service named staging.

    This is the primary method used to identify a static environment.

  • Next, Assertible checks for an environment_url in the GitHub deployment status payload. If an environment_url is found, Assertible runs tests against a transient (or "temporary") environment.

  • If the environment can't be loaded, then a core assertion failure is raised and the test runs will fail.

    The best way to avoid environment load failures is to create an environment for each static url you deploy your app too (whether staging or production).

    Please feel free to contact us if your use-case requires additional support for loading environments.

See the GitHub deployment documentation for more details

TL;DR When Assertible receives a deployment event from GitHub, it checks various fields in the payload for an Environment or Environment URL. If an Environment URL is present in the data, Assertible uses that as the base host which all tests are run against. This is known as a Transient Environment.

Remove the GitHub Deployments integration

To remove the GitHub deployments integration, you need to visit any of your web service's deployments tab in the Assertible Dashboard. From the service page, click the Deployments tab. Find the GitHub Deployments integration you want to delete, and click the trash can icon next to it.


Assertible is a turn-key testing solution for web apps. Developers and QA professionals use Assertible to write and automate tests for API's, websites, and other web services. Assertible tests and monitors your web service's behavior and health. Learn more.

Using the Assertible integration for Slack, you can:

  • send real-time notifications to your teams channel when tests are failing (or passing!).
  • see a high-level overview of the test results directly in Slack
  • view the results of a test in a single button click

Fig 1.0 Slack Integration

Setup the Slack integration

NOTE: You need a Slack account and a target channel to send messages to (e.g. #dev or #general).

  • Open one of your web service's in the Assertible dashboard.
  • Click on the Settings tab then Hooks & Alerts.
  • Find the Slack alerts integration and select Add to Slack.

    Note: The Slack integration can be customized further using the "Preferences" drop-down.

    Note: This step will lead you to the Slack website to confirm the integration. If you are not redirected directly back to your test page, navigate back to your dashboard using the "Dashboard button in the site navigation.

    Assertible dashboard GitHub status checks deployments settings


The Zapier integration makes it possible to send test results to Zapier by making a Zap that triggers when a test is run on your web service. This opens up many possibilities for how you can see and use your Assertible test result data.

Set up the Zapier integration

Beta alert! Our Zapier integration is currently in beta to become a certified app! Be sure to enable the Assertible integration from your dashboard, and send us a message if you have any questions or feedback!

Assertible Zapier Integration

To get started, visit the Settings page of any web service in your Assertible dashboard and find the Zapier hooks section as seen in the image above. From there, follow these steps:

  1. Enable the Assertible app in Zapier

    While the Assertible Zapier app is in beta, you must accept an invitation to use the app. You can find this link on the Settings page of any web service in your Assertible dashboard.

  2. Make a Zap

    After you have enabled the Assertible app in your Zapier account, you can begin creating a zap in Zapier. Start by selecting the Assertible app, and then choose one of the supported triggers.

    On the next page, you'll get a Webhook URL from Zapier that you can use in the Assertible, to create the integration. When you have that Webhook URL, proceed to the next step.

  3. Create the integration in Assertible

    Using the Webhook URL from step 2, you can now create the Zapier integration in your Assertible dashboard. The different options are described below:

    Trigger Zap

    This setting configures when the Zap Trigger wil be executed. This can either be On Test Complete or On Test Fail.

    Webhook URL

    The Webhook URL is given to you by Zapier in Step 2.

    When tests are run via

    The vias option allows you to further restrict when the Zap is triggered. The valid options here are: Deployments, Schedules, Trigger URL, and Dashboard.

Zapier Triggers

Completed Test trigger

The Completed Test trigger fires each time a test completes. You can optionally configure this to only run when tests fail. time a test fails. If multiple tests are executed at the same time (e.g. have the same Run ID), this trigger will fire for each test result independently.

Additionally, this trigger can be configured to run based on who or what executed the test, known as via. For example, via Schedule will call the Completed Test webhook each time tests are executed using a schedule. Other values which can be configured are via Deployment, via Trigger URL, and via Dashboard. Using via helps reduce executing Zaps unknowingly or at undesired times.


Psst.. Currently, Assertible only support emails hooks. Looking for another type of hook? Let us know!

Hooks are the most basic form of test automation that execute an action when a test run completes, like sending an email. Hooks are easy to set up and require little configuration and maintenance.

There are three pieces to every hook:

  • Type

    Determines what type of hook to execute, like an email hook.

  • Action

    The action let's you configure when to execute your hook:

    • On test complete: execute this hook every time a test completes
    • On test failure: only execute this hook when a test fails
  • When tests are run via

    The vias option allows you to restrict when the hook is triggered. The valid options here are: Deployments, Schedules, Trigger URL, and Dashboard.

    By default, Dashboard is ommitted to reduce unwanted emails and because it's easy to view the result status in the dashboard.

You can add a new hook from the Settings view of any web service. By default, every test on that service will be enabled for the hook. You can enable or disable specific tests by editing your hook from the same page.


Note! The paid plans allow more frequent schedules than the free plan. Upgrade today.

Monitoring tests can be configuring using schedules with flexible frequency. Schedules allow you to set up hands-off monitoring of any web service and be confident that your APIs are being tested regularly. Assertible currently supports the following schedule settings:


  • Once per Minute*
  • Once per 5 Minutes*
  • Once per 15 Minutes*
  • Once per Hour
  • Once per Day

* These frequencies are only available on the paid plans.

Start Date and Time

Choose the date and time that the schedule will start running. This can be now, or any time in the future.

Trigger URLS

Triggers provide a flexible way to run your tests from anywhere outside of the Assertible dashboard. Every web service and test has a Trigger you can call to, for example:

Triggers make it easy to integrate API testing into your workflow and run your tests when you need them most. Here's a few examples of when using the Trigger comes in handy:

  • Running your tests from your API test suite or CI pipeline
  • Running your tests against dynamic environments (like dev or qa)
  • Providing reproducible test cases to other team members.

Psst.. If you are running Trigger URLs from your continuous delivery pipeline to test releases after they are deployed, we recommend using the Deployments API instead.

Get your Trigger URL

Triggers are available for every web service and each individual test. You can find the trigger URLs in your Assertible dashboard in two places:

  • Web service settings

    Navigate to your web service's Settings tab and check the Service Settings view. There will be a Trigger URL field which triggers all tests for a web service.

  • Test configuration settings

    Navigate to a test and check the Configure area under the URL configuration component. Click the Settings tab and look for Trigger URL (you may have to scroll down).

Start API testing for free

Trigger URL examples

  • Run tests using a trigger:

    curl -XPOST
  • Run tests and specify the environment:

    curl -XPOST -d'{
      "environment": "staging"
  • Run tests against a dynamic URL (known as a transient environment):

    curl -XPOST -d'{
      "environment": "my-dynamic-environment-xyz",
      "url": ""
  • Run tests for a specific endpoint:

    curl -XPOST -d'{
      "endpoint": "/my/endpoint"
  • Wait for tests to finish and return results:

    curl -XPOST -d'{
      "wait": true
  • Run trigger URL using query parameters:

    curl -XPOST

    This comes in handy in scenarios where specifying a request body may be inconvenient. See Using a Trigger URL with Heroku deploy hooks for more details.

Note: The response body of a trigger URL is not yet finalized, so although you may use the information, be aware that it is likely the change.

Trigger URL Parameters

These parameters can be configured in the JSON request body or query parameters of a Trigger URL.

  • environment optional

    A unique environment identifier. For example, staging, qa or production.

    Environments are configured in the dashboard

    If your environment is dynamic, use this along with the url parameter to specify a transient environment URL.

    Default: production

  • endpoint optional

    Only run tests that match the endpoint. For example, / or /tests/{id}.

  • url optional

    The url parameter specifies a transient environment URL. For example,

  • wait optional

    Wait for the tests to finish running before responding. The default behavior is to respond immediately with pending results. Setting wait=true will wait for the tests to finish and respond with the finalized results.

    Default: false

Trigger URL with Heroku Deploy Hooks

The Deploy Hooks addon from Heroku along with the Assertible trigger URL allows you to run your tests every time your application deploys. You can add the deployhook to your Heroku app with this command:

$ heroku addons:create deployhooks:http \

Adding deployhooks:http to myapp...Done.

This addon will call the Trigger URL to run your API tests after your Heroku application is deployed. To get the SERVICE_ID and API_TOKEN for your service, visit the Trigger URL settings page in the dashboard.

Heads up! If your are using the Trigger URL to run deployment validation tests, you can alternatively use the Deployments API to track and test API releases across environments.

The easiest way to test and
monitor your web services

Define and test your web service with Assertible Track and test API deployments across environments Schedule API monitoring and failure alerts

Reduce bugs in web applications by using Assertible to create an automated QA pipeline that helps you catch failures & ship code faster.

Sign up for free