# Automate image resizing with Make
> Build a Make scenario that takes a new image and generates every size with SocialCutter: Create JSON, the X-API-Key header and using the outputs.
- URL: https://socialcutter.theboomer.dev/en/guides/make/
- Idioma: en
- Familia: ia
- Actualizado: 2026-09-24
- Palabras clave: Make, Integromat, no-code, automation, HTTP module, SocialCutter, API key
## Why automate resizing in Make

A master image feeds Instagram, LinkedIn, X and the blog hero, and every slot asks for a different ratio. Doing it by hand does not scale when you publish daily or the catalogue has hundreds of products.

Make fits because it already watches where new images show up and because its HTTP and JSON modules let you talk to any REST API without code. SocialCutter crops the image **centered** to the exact dimensions of each destination and returns one URL per output; the Make scenario moves that URL to the right place. The framing is centered and predictable.

## How the API works

The REST API lives at `https://api.socialcutter.theboomer.dev` and authentication goes in the `X-API-Key` header (`Authorization: Bearer sc_your_key` also works).

- `POST /api/v1/images/process` — takes an image and returns one output per destination.
- `POST /api/v1/images/upload` — accepts the image as a base64 string in the JSON body.
- `POST /api/v1/images/process/upload` — multipart with the file in `file` and `destinations` as a form field.
- `POST /api/v1/images/batch` — several images in one call.
- `GET /api/v1/history`, `GET /api/v1/wallet`, `GET /api/v1/platforms` — history, quota and the real destination catalogue.

The full reference is at https://docs.socialcutter.theboomer.dev.

## Make and binary data: the multipart difference

The **HTTP → Make a request** module can send `multipart/form-data`, but it needs the file as a real binary from a previous module (for example **Google Drive → Download a file**) plus the `destinations` field as a JSON string. That depends on two fragile things: that the binary arrives intact and that the JSON string is escaped correctly. The path that always works is not sending binary:

1. **Send the file's public URL** in the `source` field of the JSON body. It is the recommended path and the one this guide uses.
2. **Use base64** with `POST /api/v1/images/upload`, when the origin exposes no reachable URL.

If you really need to upload the file, use `POST /api/v1/images/process/upload` with body type `multipart/form-data`, the `file` field fed by the source module's binary and `destinations` as a JSON string. Test that path on its own before putting it in production.

## Create the API key

Open https://dash.socialcutter.theboomer.dev, go to **Profile → API keys**, create a key with a recognisable name (for example `make-prod`) and copy it: it starts with `sc_` and is shown only once. In Make, store it as a scenario environment variable or a connection, not pasted into a module's text.

## Building the body with Create JSON

The real request body looks like this:

```json
{
  "source": { "type": "url", "value": "https://example.com/photo.jpg" },
  "destinations": [
    { "platform": "instagram", "format": "post" },
    { "platform": "linkedin", "format": "post" },
    { "platform": "twitter", "format": "post" }
  ],
  "options": { "fit_mode": "cover" }
}
```

In Make, the **JSON → Create JSON** module saves you typing the text and escapes quotes: add `source` (object with `type` and `value`) and `destinations` (array with one object `platform` + `format` per destination). If you prefer to paste the JSON, use body type `Raw` in the HTTP module with `Content-Type: application/json`, but check the quotes: one unescaped quote returns `422`.

`source` accepts `url` or base64 and `destinations` is the list of platform and format. `fit_mode: cover` scales and crops the overflow with a centered crop (the default); to fit the whole image, use `contain` with `background_color`.

### Destinations the API accepts

| Platform | Format | Dimensions | Ratio |
|---|---|---|---|
| instagram | post | 1080x1080 | 1:1 |
| instagram | story | 1080x1920 | 9:16 |
| instagram | landscape | 1080x566 | 1.91:1 |
| facebook | post | 1200x630 | 1.91:1 |
| facebook | story | 1080x1920 | 9:16 |
| facebook | cover | 820x312 | 2.63:1 |
| twitter | post | 1200x675 | 16:9 |
| twitter | header | 1500x500 | 3:1 |
| linkedin | post | 1200x627 | 1.91:1 |
| linkedin | cover | 1128x191 | 5.9:1 |
| youtube | thumbnail | 1280x720 | 16:9 |
| youtube | banner | 2560x1440 | 16:9 |
| tiktok | cover | 1080x1920 | 9:16 |

These come from `GET /api/v1/platforms`, which is public. The catalogue has no 4:5 format.

## The call with the HTTP module

In the **HTTP → Make a request** module:

- **URL**: `https://api.socialcutter.theboomer.dev/api/v1/images/process`
- **Method**: `POST`
- **Headers**: `X-API-Key` = `sc_your_key`, and `Content-Type` = `application/json` if you send the JSON as Raw. Add `Idempotency-Key` with a stable file id so a retry does not duplicate work.
- **Body type**: `Raw` (or `application/json`), with the JSON from the Create JSON module. With `multipart/form-data`, the `file` field carries the binary and `destinations` goes as text.

Check the raw response before building the scenario:

```bash
curl -s -X POST "https://api.socialcutter.theboomer.dev/api/v1/images/process" \
  -H "X-API-Key: sc_your_key" \
  -H "Content-Type: application/json" \
  -d '{"source":{"type":"url","value":"https://example.com/photo.jpg"},"destinations":[{"platform":"instagram","format":"post"}]}' \
  | jq '.image_id, (.outputs[] | {url, platform, format, width, height})'
```

## Reading the response and using it later

The response carries `image_id` and an `outputs` array, one entry per destination, with the URL, the platform, the format and the dimensions. To use it later:

1. **JSON → Parse JSON** over the response body turns `image_id` and `outputs` into mappable fields.
2. **Flow Control → Iterator** over `outputs` walks one output per cycle.
3. In each cycle, an **HTTP → Get a file** downloads the URL if you need the binary, or you pass the URL straight to the destination module.

## Chaining to a CMS or storage

- **WordPress**: push the output to the media library (`POST /wp-json/wp/v2/media`) and set the attachment id on the post's `featured_media`.
- **Shopify**: use the product `image` field with the output URL.
- **Storage**: the upload module needs binary; download the output first with an HTTP `GET` step, then upload. If it rejects binary, let the CMS download the URL instead.

## Plan limits

- **5 MB** max per image; above that the API answers `413`.
- **1 use per destination** (platform and format) per request. Repeated destinations are not charged twice and failed items are refunded.
- Daily quota per plan: Free (€0) 3 uses/day, Basic (€3) 10/day, Pro (€9) 30/day, Agency (€29) 100/day. All include API and MCP.
- In Make, every module spends one operation from your plan: an Iterator spends one per item.

## Common errors

| Code | Meaning |
|---|---|
| 401 | The `X-API-Key` header is missing or the key is wrong |
| 429 | Quota exhausted: you passed the daily uses of your plan |
| 413 | The image is over 5 MB |
| 422 | Validation error: `source` or `destinations` are malformed, or the JSON is broken |
| 400 | Invalid payload: unknown platform or format |

## Cost per request

1 use per destination. A scenario asking for Instagram post, LinkedIn post and X post costs 3 uses per image. If the trigger gets bursts, group them before calling or use `POST /api/v1/images/batch`. Check `GET /api/v1/wallet` for the daily quota.

## Next steps

- n8n guide: [Automate image resizing with n8n](/en/guides/n8n/)
- API guide with curl: [Process images from the terminal](/en/guides/curl/)
- Python guide: [Automate SocialCutter with Python](/en/guides/python/)
- WordPress guide: [Integrate SocialCutter with WordPress and WooCommerce](/en/guides/wordpress/)
- API documentation: https://docs.socialcutter.theboomer.dev