Skip to content
All posts
ecommerceapiautomation

Generating a creative for every SKU without a designer per SKU

A catalogue of ten thousand products needs ten thousand offer cards each sale — and different ones when the discount changes. Here is the loop that does it.

The pixbix team · Engineering2 min read

Every sale, the same conversation. Marketing wants offer creative for the whole catalogue. Design has capacity for the top fifty products. Everyone agrees to do the top fifty and feel bad about it.

Design once, expose three fields

Build the offer card once. Then decide what a caller may change — usually less than you would expect:

  • product — the image
  • headline — the campaign line
  • price and mrp — the numbers
  • badge — the discount flag

Everything else is locked. The brand colours, the logo placement, the safe area the price sits inside: none of it is reachable through the API, so none of it can drift.

The loop

curl -X POST https://pixbix.app/api/v1/render \
  -H "x-api-key: $PIXBIX_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "templateId": "product-offer-square",
    "values": {
      "headline": "Monsoon Sale",
      "product": "https://cdn.example.com/sku/1042.jpg",
      "mrp": "₹2,499",
      "price": "₹1,249",
      "badge": "50% OFF"
    },
    "output": { "format": "png", "scale": 2 }
  }'

Image renders resolve synchronously, so the response carries the finished CDN URL. Take it straight into your feed, your ads or your storefront.

Three things that make it survive production

Price it before you run it. POST the same payload to /v1/render/estimate and you get the credit cost back without rendering. Worth doing once at the top of a batch so a ten-thousand-item loop does not stop halfway through.

Use an idempotency key. Retries happen. Sending Idempotency-Key means a repeated request returns the original render instead of billing you twice for the same card.

Watch concurrency, not just credits. Credits stop you spending more than you bought; concurrency is what stops one job occupying every worker. If you are pushing a large batch, your plan's concurrent-render limit is the number that actually governs throughput.

When the price changes

Re-run the same loop. The layout does not drift, so the new run is the old run with different numbers — which is exactly what you want and exactly what a human redoing it by hand cannot promise.