Web services allow you to create and organize a set of common request settings. Every test utilizes a web service.

By using a web service, it's possible to set up Authentication for the Host URL, and configure other settings to be used between tests. Web services allow you to easily test new endpoints without the need for boilerplate.


Configuring a Web Service


The name of the web service. Usually this is something as simple as "Assertible API". If API settings are imported from a Swagger specification, the name (and most other settings) will be created automatically.


The Host is the base URL for where your API lives. For example: in https://api.assertible.com/tests the Host would be api.assertible.com. Or if you wanted to test a website, say https://assertible.com/plan - then the Host would be assertible.com.

Using the 'root' of your web service as the API Host allows you to easily create test for new endpoints and share settings between tests.

The web service host is also the default environment host. This host is used as the base URL for all test runs directly from the dashboard and can be dynamically changed when using trigger URLs and other integrations.


Heads up! Auth is stored in plain text; it is not encrypted. Please take care to use non-critical API tokens when creating web services and tests. We are working on a secure solution and will send out an email when it is deployed.

If the web service you are testing requires authentication to make requests, you can configure the default [auth]#(auth) in the web service settings. When a test is created, it will automatically use the API's default auth. Tests also have settings to override the auth when necessary.

Assertible supports the following auth types:

  • Basic Auth
  • Digest Auth
  • oAuth v1.0a
  • oAuth v2.0
  • API Token Auth
  • No Auth

If you need to use an auth that is not supported, you can probably configure it directly in a request Header for your test.


Schemes are the HTTP protocols that your web service supports: either HTTP or HTTPS or both. These are not required for a web service. When a scheme is configured, tests for that web service will know which schemes are supported. You can set or override the scheme used on any test in the test configuration.

Importing a web service

If you have a spec for your web service, like Swagger, you can import your entire web service configuration and create tests for every documented endpoint. Incredible!

Note! If your API spec is in a format that is not Swagger, try using https://apimatic.io/transformer

To import a spec, visit the Web Service Overview page of the Assertible dashboard. You can import your spec from a file or URL:

Fig 1.1 Import API Spec

Importing a swagger spec

Swagger is a popular specification that describes everything about your web service: endpoints, auth, query parameters, etc. With Assertible, you can import your Swagger spec to acheive:

After importing your Swagger specification, you'll have runnable tests for your whole web service.

Heads up! You must import the .json version of your spec. Yaml support is on it's way.

Hooks and automation

With every web service, you can set up hooks, integrations, schedules, etc to take action when something is failing with a web service. Assertible has support for the following automations:

You can read about the following in more detail in the automation section.

Web Service Badges

Each web service has an embeddable badge for displaying the current status of all test assertions for the latest test runs. You can use this to communicate the current status of a web service with team members or within documentation pages. The badge will display the current web service test result state at any given time.

Fig 1.5 Embeddable web service badges

Here are a few examples of using badges in other formats:


[![Assertions Status](https://assertible.com/apis/{{api-id}}/status?api_token={{token}})]


<img src="https://assertible.com/apis/{{api-id}}/status?api_token={{token}}" alt="Assertions Status" />


An environment is a unique host for a web service and contains the required settings for making requests to HTTP endpoints related to a web service (e.g. SSL validation and hostname).

For example, staging.assertible.com could correspond to an environment named staging whereas assertible.com would be named production. This makes it easy to run the a set of tests against different instances of your web service.

Environments are used by Trigger URLs and the Deployments API to specify the unique host URL to use when your tests are executed.

Environments are also used by service integrations such as the GitHub deployments integration. The image below shows a web service which was deployed to an environment named assertible-staging using the GitHub API.

Assertible GitHub status check

For more info about our GitHub integration, see the "How it works" documentation.

Validate SSL

When the "Validate SSL" setting is enabled for a web service environment, validations are run on the SSL certificate for the request. For example, in the case of an SSL hostname mismatch or certificate expiration, the AssertValidSsl core assertion would fail.

NOTE: Validate SSL is used on all HTTP requests invoked by tests including setup steps.