CI/CD Integrations


Continuous Integration and Continuous Delivery (CI/CD) tools aim to increase efficiency by forming a standardized testing and deployment process for your engineering teams.

Since correct tag implementation is often the responsibility of the development and/or QA team, it makes sense to put ObservePoint somewhere in that process. After working with many customers we have identified a few powerful use cases for ObservePoint integrations with CI/CD tools.

  • Kick off audits on a specific web site with a list of changed URLs
  • Kick off a list of audits and journeys at the time of regularly scheduled releases to catch implementation issues
  • Kick off audits and journeys during scheduled maintenance times in lower environments to prevent data loss
  • Use audit and journey rule failure notifications to create new JIRA tickets requesting implementation fixes

Since every team has a different testing and deployment workflow, whatever integration you build will likely be custom, but can still be guided by one of the use cases above.

Building out this integration should be a simple process for those familiar with CI/CD tools. The core of the integration is leveraging the ObservePoint API to start a list of pre-determined Audits and Journeys.

Below is a guide to help your quality assurance or devops team integrate ObservePoint with your development processes:

Basic Example

This example demonstrates how to use the API to start an Audit, Web Journey, or App Journey.

To make this call, you can use the following ObservePoint endpoint with a POST method:

You will need a header with a key named “Authorization” with the value api_key {your api key here} which you can find here.

Finally, as this is a POST request you will need to attach a JSON payload to the request body. For this request, this will look like the following:

{"auditIds":[], "webJourneyIds":[], "appJourneyIds":[] }

For each of the empty arrays in the above payload, you can put IDs of the audits, journeys, or app journeys you would like to have started at the time of execution.

Here is an example of a JSON body for an API call that triggers 1 Audit and 1 Web Journey to run:

{"auditIds":[84672], "webJourneyIds":[19845], "appJourneyIds":[]}

Note: Not every parameter in the body is required. You can delete them or leave the arrays empty.

Here is another example where a JSON body in an API call triggers 2 App Journeys to run:


To find the IDs to fill these arrays, you can simply go to the audit or journey you would like to have started and look at the URL. The ID is the first number you see:

Jenkins Example

One of the most popular CI/CD tools is Jenkins. In this example, we use Jenkins to leverage a simple cURL call to start two audits and one journey.

The code below is a sample Bash command using a cURL call to run audits and journeys. In this example it runs audit IDs 123456 and 78901, and web journey ID 56789: \-H 'Authorization: api_key xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' \-d '{"auditIds":[123456,78901],"webJourneyIds":[56789],"appJourneyIds":[]}'

The usage obviously doesn’t end with kicking off audits. The ObservePoint API can be leveraged to do processing before kicking off these audits. As mentioned, you can import a list of URLs that you would like to have scanned, push those URLs to an audit, then kick off the audit to be processed.

After the audit runs you can create JIRA tickets for your teams, based on audit or journey rule failures or simply send a notification to your team over Slack or Microsoft Teams (see WebHooks Use Cases). These are just some examples of the many customizations you can add to your CI/CD process.

Reach out to your consultant to determine use cases and next steps to implement a CI/CD integration.

Did this answer your question? Thanks for the feedback There was a problem submitting your feedback. Please try again later.