Ideogram 4.5 low to high on one order: new Idempotency-Key or a 409

A common flow with Ideogram 4.5 is a cheap quality: "low" draft followed by a high final for the same order. If both calls use the key order-8823, the second is a different payload under the same key, and Sume answers 409 idempotency_conflict. The error details carry the original job's id, status_url and result_url, so you can tell what the key already belongs to.

The conflict is the safety working. The fix is not to retry; it is to name the two calls differently.

Key from the order and the payload

Hash a canonical form of the payload so field order cannot change the key, and keep the result well under the 255 printable character cap.

import hashlib, json

def image_key(order_id: str, payload: dict) -> str:
    canonical = json.dumps(payload, sort_keys=True, separators=(",", ":"))
    return f"{order_id}-{hashlib.sha256(canonical.encode()).hexdigest()[:16]}"

base = {"model": "ideogram/ideogram-v4.5", "prompt": "Cafe menu poster", "resolution": "1K"}
draft = {**base, "quality": "low"}
final = {**base, "quality": "high"}

print(image_key("order-8823", draft))
print(image_key("order-8823", final))   # new quality, new key, new job
print(image_key("order-8823", draft) == image_key("order-8823", dict(reversed(draft.items()))))

What each key means

Practical rules

• Include model, quality, resolution, n and the prompt in the hashed payload.
• A deliberate quality upgrade is a new, separately billed job. That is what you want for a draft then final flow.
• On idempotency_key_in_use, wait and retry the same call; on idempotency_conflict, do not.
• Store the key before you send, so a crash can resume with the same key.