---
title: "Delivery Modes - Stream, Host, or Sign Your Renders"
description: "Choose how a render comes back - streamed bytes by default, a hosted URL you can store, or a signed URL that expires. One parameter, no manual re-upload step."
url: "https://www.imejis.io/changelogs/image-api-delivery-modes"
image: "https://www.imejis.io/images/changelogs/api-integrations-hub.png"
published: "2026-08-12"
author: "imejis"
---

# Delivery Modes - Stream, Host, or Sign Your Renders

## Delivery Modes

Not every integration wants raw image bytes back. A spreadsheet wants a URL. A webhook wants something it can hand off. A public embed wants a link that eventually expires. The new `?delivery=` parameter lets the render decide how it comes back.

### The three modes

```http
GET https://render.imejis.io/v1/<design-id>?delivery=signed&expiresIn=120
```

- **`stream`** (default) - the image bytes come straight back in the response, ideal for rendering inline or piping to a file.
- **`hosted`** - we store the render and return a JSON body with a stable URL. Drop it in a spreadsheet, a CMS field, or an email.
- **`signed`** - same stored URL, but time-limited. Add `expiresIn` in minutes (default 60, up to 7 days) and the link stops working after that.

No more rendering to bytes just to upload them to your own S3 or Cloudinary bucket to get a link. Ask for `hosted` or `signed` and the URL is the response.

### A note on API keys

Your `dma-api-key` authorizes a render. Keep it server-side. Don't bake it into a public GET URL where anyone could read it and spend your quota - render with your key on the server, then hand out a `hosted` or `signed` URL instead. See [API security best practices](/blogs/tutorials/image-api-security-best-practices).

Full details and examples are in the [delivery modes guide](/blogs/tutorials/image-api-delivery-modes).