Postbacks are the callbacks that Blitline makes to YOUR application when Blitline has finished executing a job. Since Blitline jobs are asynchronous (they are done on multiple threads, concurrently), you cannot simply submit a job and get a completed job JSON back. This is where postbacks come in... we can notify you as soon as we are finished with a job. This is the PREFERRED method over polling.

  Guaranteed Delivery

Postbacks are guaranteed to happen, even if there is an error. You will always be called back when a job completes.


You define where we send your job information. Nobody has access to the data except the postback endpoint.


Polling is not a scaling solution for either of us. We cannot handle infinity connections for polling, so if there are no connections for polling, you won't be able to poll. Postbacks are GUARANTEED because they are 1 single call from us to you.

  Zero latency!

Your code gets called as soon as the job is completed. Before our jobs have even exited, you app can be taking the data and running with it. This means postbacks are the fastest possible solution for your app.


What JSON gets posted back?(or returned with long polling)

Postbacks are http calls that Blitline ’POST’s back to your server, notifying you that the image has completed.

  • resultsRoot node(required: 1 time)
    • job_idOriginal id returned by the job submission(required: 1 time)
    • original_metaThe metadata associated with the original photo(required: 1 time)
      • widthWidth of original image(required: 1 time)
      • heightHeight of original image(required: 1 time)
    • imagesThe list of images processed by Blitline(required: 1 time
      If successfull
      • image_identifierImage identifier you submitted with JSON with original job(required: 1 time)
      • s3_urlDestination url of image(optional: 1 time)
      • metaMetadata about image(optional: 1 time)
        • widthWidth of image(optional: 1 time)
        • heightHeight of image(optional: 1 time)
        • latLatitude of image (if available)(optional: 1 time)
        • lngLongitude of image (if available)(optional: 1 time)
      • extended_metaBlob (string) of data represnting all the metadata stored in original image(optional: 1 time)
      If failed to process ("v" > 1.19)
    • errorsText associated with error that occurred(required: 1 time)
    • failed_image_identifiersArray of image_identifiers that were not completed(required: 1 time)



Postbacks are more effort than just polling... we know. The concept is simple, though. You give us a URL to call when we are done processing a job.  Simple, right?

How can I give you a URL when I'm developing on my local machine?

We have two answers for this...

Option #1
You could just use polling for development, build the approprate client methods, and then switch over to postbacks when you are close to deployment. We are FOR polling in development, it's just not a scalable end solution for production.

Option #2
You could use localhost tunnelling. Which allows you to open your localhost so that it's available to receive data from the internet.
See our walkthrough here...

I don't have a server to call back too, how can I use a postback?

OK, well you've got us there... In this case you options are limited. BUT, there is a better answer than polling us...

Option #1
Poll the location of where the image is going to GO. For example, if you are sending it to S3 you already "know" the S3 url where it's going to end up, so poll that location. We have a simple javascript routine for polling S3 here.