Getting Started

​ ​Welcome

Blitline Job

Job Response

Job Options


Polling and Postbacks


Development Recommendations

Service Limits

Examples List

List of Available Functions

Output Options

S3 Destination

IAM Users

S3 Signed Url

Azure Destination

FTP Destination

Other Service Signed Urls





Color Extraction

Static IPs

Signed Jobs



Image Optimization

Smart Image




Special (Non-Image) Processing

AWS Rekognition/Facial Recognition

Apache Tika

Vector Processing

Animated GIFs

Screenshots of Websites

IM Scripts

Video Keyframes


​ ​Trancoding Video Presets

​ ​Video Transcoding

​ ​Find Image on the Internet

Building Gifs or Videos from Images


Updated 7 months ago ​by Blitline Support

Blitline lets you run massively parallel automated image processing jobs in the cloud.


First you must log into Blitline and get a FREE developer account. When you register, you will get an Application ID which is your secret token you will use for all you processing jobs.


Clients submit JSON to Blitline defining image source and the sequence of operations that one wishes to perform on the given source image. You can pipeline many different operations and output to many different locations and filetypes.


There is a single primary endpoint which you can submit your JSON to. This is a POST to:


The scope of the JSON you submit is larger than we will dive into here, but it is based on the notion of a “job”. This “job” is an atomic entity which encompasses all the operations you wish to perform on a single image. You can have multiple “jobs” in a single submission, but you must have at least 1 job to perform any actions.


Scalable applications require layers that absorb load and distribute that load across workers that can be scaled up and down as that load ebbs and wanes.

When jobs are submitted to Blitline, they are put into distributed queues that hold the data until backend servers can pick them up and process them. This processing (on average) takes about 30ms, but that can vary based on load.

When jobs are picked up by Blitline workers, they are executed, images produced and output, and postbacks(webhooks) called and clients notified.

For this process to function well, it is optimum for clients to define a postback_url which is a URL of the client’s that Blitline can call to notify them that the job has completed. While it IS possible to poll for completion, it is not recommended for production.

You can see a prezi presentation describing Blitline workflow here



Not many people would argue that S3 or Azure are probably the largest, fastest, best outfitted platforms for uploading images to. It is not reasonable to think that Blitline could reach a level of upload performance that these platforms have, so we have decided there is little need for us to try to compete in this space. The amount of hardware we would need to possess to handle 8,000,000 uploads/hr would be phenomenal, yet S3 handles it without issue.

“But isn’t uploading to S3 then having Blitline download from S3 a waste of time and a burden on the end-user?”

Barely. It’s less than you might think. We run many EC2 instances, and the network speed between S3 and those instances is blazing fast. Those speeds approach (if not surpass) hard drive speeds. So reading from S3 is close to reading from a local hard drive (for Blitline).

How did we do?