For developers · API access on Pro and Enterprise

One POST, one transparent PNG.

A single endpoint, bearer auth, and a file back. No SDK to adopt and nothing to keep in sync.

Read the API reference Plans with API access

POST 200 OK

curl -X POST \
  "https://api.qikkstools.com/v1/remove-background" \
  -H "Authorization: Bearer $API_KEY" \
  -F "image=@product.jpg"

returns product.png · alpha

Three shapes

Where the call belongs

Cutting an image takes seconds, not milliseconds. Which of these you pick is really a question about who is waiting.

Shape 01 user waiting

On upload

Call it inside the request that accepts the file, and hand back the cutout in the same response. Simplest, and the one that hurts when the network is slow.

Show a spinner, set a timeout

Shape 02 queued

Behind a job

Accept the upload, enqueue the cut, notify when the PNG lands. What most production integrations end up as.

Retry on 5xx, keep the original

Shape 03 nobody waiting

Nightly batch

Walk yesterday's uploads through the batch endpoint on a schedule. Cheapest per image and nothing user-facing to break.

/v1/batch-process

Before you build

What the API is not

Read this before writing the wrapper, not after.

No official SDKs: It is one HTTP endpoint. Your language's standard client is the integration, and there is nothing to keep up to date.
Not free: The browser tools are. API access sits on Pro and Enterprise — the plan page states the limits per tier.
Not real time: A cut is seconds of model time. Design the call as an asynchronous step rather than something a page render waits on.
Images only: Stills in, stills out. There is no video endpoint, and frame-by-frame is not what this is for.

Read the reference first

Endpoints, authentication, errors and batch limits — all of it on one page.

API reference Talk about volume