Runscope API Monitoring    Learn More →

New and improved options for programmatically interacting with Runscope Radar

By John Sheehan on .

Every team works with their APIs a little differently. Because of the variety of environments our customers have, it's important that we provide flexible extensibility options to make sure we allow developers to build integrations we may not be able to build ourselves. We offer three main ways to do that: the Runscope API, Radar webhook callbacks, and Radar Trigger URLs.

Over the past few months we've been improving these extensibility points based on your input and feedback. The backlog of undocumented features was getting a little long, so we've documented them all and have summarized the changes below (with a bonus Passageway feature).

Radar: Test Results API

We've added additional endpoints to the Runscope API (for interacting with your Runscope account data) for Radar tests and results. You can use this API to build your own test status dashboards or integrate with other services that don't accept webhooks. 

Learn more 

Radar: Trigger URL for All Tests in Bucket

We've added a Trigger URL that will queue a test run for all tests within a bucket. This is similar to the "Run All" button on the Radar test overview page. Bucket-Wide Trigger URLs support custom variables and can be found in the Bucket-wide Settings.

Learn more

Radar: Batch Trigger URL

Sometimes you want to run a single test with multiple sets of initial variables in one go. The Batch Trigger URL supports just that, allowing you to start up to 50 test runs for a single test at once, each with a unique set of initial variables. 

Learn more

Radar: Additional Trigger URL Response Data

All Trigger URLs have been updated to use a new response format that will detail the one or more runs that were initiated, including the resolved initial variables (the variable state after bucket-wide and test-specific initial variables and scripts have been processed). The response also includes the agent ID or region code that will execute the test run.

The new response is returned when using a Trigger URL ending in /trigger, bucket-wide Trigger URLs, or the Batch Trigger URL. For backwards compatibility, Trigger URLs using the previous format (URLs ending in /start or /run) will continue to function indefinitely. We recommend migrating to the latest version at your earliest convenience.

Learn more

Radar: New Trigger URL Options for Locations

Two new parameters are now supported for choosing which locations to use for the test runs initiated by the Trigger URL. You can specify one more more runscope_region parameters to initiate test runs is specific geographic locations. If you're running the Radar agent in your infrastructure, you can specify one or more runscope_agent parameters to start a test run using the specific agents.

Learn more →

Radar: Additional Webhook Notification Payload Information

The payload delivered for webhook notifications has been updated to include the location (region or agent) the test run was executed in, more details about the requests executed (including response time, size and status), and the initial variable state before the first request was executed.

Learn more →

Radar: New Data Sent to New Relic Insights and Keen IO Integrations

Location (region or agent) for a test run is now included in the test run event data sent to New Relic Insights and Keen IO.

Radar: New Built-in Function

A new built-in function to generate a random string of up to 1000 characters is now available. Use {{random_string(10)}} (replacing 10 with your desired length) to use the new function in your request templates.

Radar: New Script Functions for URL-safe Base64 Encoding/Decoding

Radar Scripts can now use atob(input) and btoa(input) to do a URL-safe Base64 encoding or decoding of a string. This mirrors the functionality of window.atob() and window.btoa() in browsers.

API: Delete Bucket

The API now supports deleting buckets (except the default bucket on an account) by key.

API: Share Request

A new endpoint has been added to support creating a public share URL (similar to sharing a request in the dashboard) for a given message.

Passageway: Predictable URLs

Passageway generates a unique tunnel URL on each initialization of the agent. This can be annoying if you're using Passageway as part of a CI process. Using the new --fixed command line flag you can get a consistent URL between runs of the agent.

Keep up With the Latest Updates

Be sure to follow @Runscope and keep your eye on the Changelog for all the latest product updates new features.

Categories: announcements, product

Everything is going to be 200 OK®