Blitline Polling has changed!

We are deprecating the old polling. Don't worry we will continue to keep the old mechanism alive, but we recommend you change because the new way is a much better solution! Read below to find out why...

The better solution... Long polling

  One Call Only

Long polling lets you make one call and that call will wait until the server pushes a response back to it. No more repeatedly pinging the server.

  Works in Javascript

Single call implementation in javascript lets you make a single asynchronous call, and the server will tell you when it's done

  Same postback data

The results from the long polling are the same as if the server had called you back. Polling data is now unified with callback data

  No more latency!

With the old polling, if the server finished 1 millisecond after the poll, you would have to wait until the next poll. Now your code gets called as soon as the job is completed.


Show Me How



Javascript (jquery)

    url: "http://cache.blitline.com/listen/[JOB_ID]",
    success: function(data) {
        alert("Got data=" + data)


var options = {
  host: 'cache.blitline.com',
  port: 80,
  path: '/listen/[JOB_ID]'

http.get(options, function(res) {
  res.on("data", function(chunk) {
    console.log("Data=" + chunk);

Ruby (irb)

require 'net/http'
require 'thread'
require 'json'

Thread.new {
    url = "/listen/[JOB_ID]"
    response = Net::HTTP.get('cache.blitline.com', url)
    data = JSON.parse(response)
    puts "Data=" + data.inspect


curl 'http://cache.blitline.com/listen/[JOB_ID]'

Simply replace [JOB_ID] with the 'job_id' you get back when you POST to the /job API.

The JSON returned is the same as with postbacks


  • Prefer postbacks over long polling. Polling may fail, postbacks are guaranteed.
  • Results will only be cached for 5 minutes after end of job...get em' while they're hot!
  • Use resonable timeouts when long polling, if you don't have a result in 30 seconds, you probably aren't going to get one.
  • Remember that if you are using a platform that blocks on http get calls, make sure you use a thread to listen.
  • Use common sense, we have a finite number of connections for long polling. Don't deploy apps to 1M users that all use javascript long-polling. We, as always, reserve the right to rate limit or block overly heavy polling calls. See more here.