Blitz Docs

Partners | API Specification

Blitz partner API is loosely based on the Heroku add-on API. All partner API calls to Blitz are sent to and further protected by a pre-shared secret for Basic authentication. In the examples below, we assume that you, the partner, is awesome. In addition, we assume that you have a notion of a user that owns multiple apps and Blitz can be added/removed to any one of these apps. All of the API calls below reflect this 1-many mapping.


Invoke this when your user adds Blitz to one of their apps.
POST /awesome/resources
  awesome_id: "",
  email: "",
  first_name: "foo",
  last_name: "bar",
  plan: "500",
  domains: [

The awesome_id is the unique app id and should be of the form <id> since this is a primary key of sorts in our database. This also allows us to keep the different partner apps separate without namespace collision. The email is your user's email address and the first time they add Blitz to their app, they'll be greeted with a friendly welcome email. We recommend all of our partners to give us the name of the user, since most of the Blitz UI addresses the user by first_name in various messages, fail whales and so on. When a user directly signs in to Blitz, they need to prove that they own the app before rushing it. The domains part of the POST request, allows you to specify a list of DNS names that you know that the user owns. This allows us to pre-authorize these domains so your users can instantly load test these.

If all's okay, on our side, you'll get this as our response:

  id: "",
  config: {
    BLITZ_API_KEY: "123456789abcdef"


Invoke this when your user removes Blitz from their app:

DELETE /awesome/resources/:id

where id is the unique app-id that was used in the provision call. We'll return you with a

{ ok: true }
if it was successful on our side.

Plan Changes

Invoke this when your user upgrades or downgrades to a new plan:

PUT /awesome/resource/:id
  plan: "1000"

where id is the unique app-id that was used in the provision call. We'll return you with a

{ ok: true }
if the plan change was successful on our side. As mentioned above, we do require our partners to pro-rate plans on a daily-basis. Either that or provide the user with an option to buy a Blitz plan for a day. Unlike most other services, load testing has a much higher resource cost per-user. While we auto-scale and over provision, this helps us ensure that our users have an awesome experience.

Single Sign-On

After your user adds Blitz to an app, use this to have the user single sign-on into Blitz on behalf of the app:

GET /awesome/resources/id?token=token & timestamp=timestamp

Here token is a SHA1.hexdigest(id + ':' + sso-salt + ':' + timestamp). If the token is valid, then Blitz will automatically sign-in the user without requiring any credentials. The id in the URL is the unique app-id used in the provisioning.

Try our Starter plan free for 14 days!
Start my Trial