ConnectWyze

API & integration

Programmatic creative generation via API

Put creative generation inside your product, CMS or internal tools — one render endpoint, your infrastructure.

The problem

Teams building marketplaces, SaaS products or internal tools often need creative generated on demand: a seller boosts a listing, a user publishes a post, a campaign fires, and an on-brand image has to exist at that moment. Standing up a rendering pipeline in-house means running headless browsers, managing fonts, and fighting inconsistency between preview and output — undifferentiated work that stalls the actual feature.

From your data to finished creative

Fields in your feed

  • template id
  • variable payload (JSON)
  • image URLs
  • output sizes
  • callback / webhook URL
  • idempotency key
  • workspace storage target

How it works

Design a template in the visual editor, then call the render API with a JSON payload of variables. ConnectWyze renders the image (or a full multi-size set), delivers it to your workspace storage, and fires a webhook when it's ready. Idempotency keys make retries safe, and because the same engine powers the editor and the API, what you preview is exactly what the endpoint returns.

What you get

Single render endpoint

POST a template id plus variables; get back a hosted image URL.

Webhooks & callbacks

Fire-and-forget renders that notify your system the moment they finish.

Idempotency keys

Safe retries — the same key never double-charges or double-renders.

Your storage, your URLs

Renders land in your own R2, S3 or GCS bucket. No vendor lock-in on assets.

Preview / output parity

The API uses the same engine as the editor, so output matches the preview exactly.

The outcome

Ship on-demand creative as a feature of your own product without building or operating a render farm — one API call, results in your storage.

In practice

One API call instead of a render service

A product team embedding creative generation in their app.

  1. 1

    Situation

    They needed on-brand images generated on demand inside their product, but running a render pipeline in-house was undifferentiated work.

  2. 2

    What they set up

    They call the render API with a JSON payload, receive results in their own storage, and rely on webhooks and idempotency keys for safe async runs.

  3. 3

    Result

    Creative generation shipped as a feature of their product without building or operating a render farm.

One API call replaced a rendering service we were dreading building.
Staff engineer, product team

Zero infra

No render farm to operate

Frequently asked questions

What does a render request look like?

A POST with a template id and a JSON object of variable values (text, image URLs, sizes). The response returns the rendered image URL, or a webhook fires when an async batch completes.

Can renders go to our own storage bucket?

Yes. Each workspace can point at its own Cloudflare R2, AWS S3 or Google Cloud Storage, so generated assets live in your infrastructure.

How do you handle retries and duplicates?

Idempotency keys make repeat requests safe: the same key returns the existing result instead of rendering or charging again.

Is the API output identical to the editor preview?

Yes. The editor and the API render through the same Chromium engine and the same template HTML, so there's pixel parity between preview and output.

Other solutions