assets parameter added to v1/diff recently added a new parameter for incoming requests. By sending an additional property of “assets” with a value of true, will then include all assets that are generated, in addition to the default composite and montage images. This includes thumbnails, as well as transparent overlays.

The primary use case of this parameter is to get the persistent location of screenshots used in the job, to then use those images in future jobs.

Sound confusing? Consider the use cases below:

Use case #1: you want to have daily differences generated, but you also want to generate a month-to-month comparison, as it represents the changes that occurred during a reporting period.

Use case #2: you want to capture the state of a page prior to a cms, plugin, or module upgrade. Then later, once upgrades have been completed, you can submit a new job for a before-and-after impact assessment. Select representative pages or compare the whole site.

Use case #3: using a service like, developers can confirm the visual impact of local changes against production or prior development version. Understand the impact before even pushing to a remote repository, and certainly prior to merging into a staging/review environment.

In summary, any time you are not following the live page-to-page pattern or live page-to-self pattern, this new parameter is probably useful for you. Creating custom workflows, dashboards, or if you integrate into other applications, make sure you pass this parameter in your call.


Update: With the addition of this feature, requests will always create a separate assets.json file in addition to the results.json. This happens even if you did not include the the assets flag.

Looking to build a process or workflow around, get in touch with

ruby example

Don’t worry, a gem is also in the works 🙂

php example

Don’t panic, a WordPress plugin is in development. As is a Drupal module. :: api

We use JWT to ensure that api requests (claims) are generated by your account or CMS plug-ins. First create your object and encode it as JSON, then you create a JWT using a process like the below (in javascript):

This will result in a token like:


Then you POST the request (no body required) to:{apikey}/{token}

If all goes well you should be sent a 303 redirect, landing you on a response like the below:

{diff: “io”status: “pending”}

Once the job has been processed, you will be able to retrieve the results at the same address. The output will be json which looks like the below:

diff: “io”,
status: “success”,
url: “”,
from: “2015-03-10 15:08:42 UTC”,
to: “2015-04-05 04:52:00 UTC”,
different_pixels: 0,
total_pixels: 2583000,
job_took: “28 seconds”,
composite: “{date}/{jobid}/composite.png”,
montage: “{date}/{jobid}/montage.png”


Every account comes with a channel, so you can stream requests as they happen. We’ll cover how to listen to this channel in a future blog post. As well as the types of requests supported by

If you are looking for a JWT library for your language of choice, checkout



Want to visually track any site on the internet, sign up today or contact us with questions.


Quoting the IETF draft:

JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JavaScript Object Notation (JSON) object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or MACed and/or encrypted.