What the API actually covers
Picnie's developer tools expose the core image operations as endpoints: cutting backgrounds, resizing to exact dimensions, compressing for delivery, and rendering a template with variables you pass in the request body. Anything you can do by hand in the dashboard has an equivalent call in the API reference.
Authentication and a first request
Requests are authenticated with an API key sent in the request header, scoped to your account. A minimal first call is usually a template render: send a template ID and a small JSON object of field values, and get back a URL to the rendered image - no dashboard interaction required.
Background removal from a script instead of a dashboard
- Send an image URL or file to the background removal endpoint.
- Get back a transparent PNG you can immediately place on another background or into a template.
- Trigger this per upload in your own app - a product listing form, a user profile photo - instead of asking users to use a separate tool.
Resizing and rendering templates by API
- Design the template once in Create Images Online and note its field names.
- Call the render endpoint with a JSON payload mapping those fields to real data.
- Pass the result through the resize endpoint if you need multiple output dimensions.
- Store or serve the returned image URL directly from your application.
Chaining endpoints into one pipeline
Most real workflows combine steps: remove a background, place the cutout into a template, then resize the output for three different placements. Because every step returns a usable image URL, you can feed one endpoint's output straight into the next call without downloading and re-uploading files in between.
Rate limits, errors, and production habits
Treat image endpoints like any external dependency: handle non-200 responses explicitly, retry transient failures with backoff, and avoid firing thousands of synchronous calls from a request handler - queue bulk jobs instead so a user-facing request never waits on a batch render.
A concrete example: a profile photo upload flow
A typical use case looks like this: a user uploads a profile photo in your app, your backend calls the background removal endpoint on that upload, then calls resize to produce a properly cropped avatar at the exact dimensions your UI expects. The user never sees Picnie directly - from their perspective, they uploaded a photo and got back a clean, correctly sized avatar a moment later.
Idempotency and duplicate requests
Network retries happen, and a naive integration can end up calling a render endpoint twice for the same event. Where possible, generate a request identifier tied to the source event (an order ID, an upload ID) and check whether that identifier has already been processed before firing a duplicate render - this matters more for template renders tied to billing or delivery than for simple one-off resize calls, but it is worth building the habit early rather than retrofitting it after a duplicate-send incident.
Verifying webhook payloads before you trust them
If you are receiving webhooks from Picnie rather than only calling endpoints yourself, verify the request signature before acting on the payload, the same way you would for any other webhook provider. Skipping that check works fine in a demo and becomes a real liability once the endpoint is public and processing real user data - treat webhook verification as a required step, not an optional hardening pass for later.
Local testing before deploying an integration
Test each endpoint against a small, disposable set of sample images and known template fields before wiring it into a real feature - a broken mapping caught locally in five minutes is far cheaper than the same bug surfacing in production against real user uploads. Keep a short set of edge-case inputs (a missing field, an oversized image, an unusual aspect ratio) on hand specifically for this kind of pre-deploy check.
Where the docs pick up from here
The API reference documents every endpoint, required parameters, and response shape. If you would rather trigger renders from a no-code trigger during prototyping, the same templates work through Picnie integrations before you write a single line of backend code.
Start building on Picnie
Get your API key and see endpoint examples at Picnie for Developers, or jump straight into the API reference.
Picnie at Picnie. Writes about image automation, developer experience, and shipping product faster.