Higgsfield 423 and 503 model errors vs Sume provider capacity

Higgsfield's docs say a model that your account cannot use can return 404, 423 or 503, with 423 meaning the model is temporarily blocked and 503 meaning it is disabled or not ready. Sume splits the same situation in two: provider_capacity_exceeded means the dispatch queue is full and you should retry later, and provider_not_configured means provider execution is not available in this runtime.

Higgsfield: three codes, one question

Higgsfield marks 423 and 503 as retry later, and 404 as no. That leaves you guessing between a model that is blocked for a while and a model your account was never given. Check the model list for your account before you build a retry loop on either code.

Listed only when configured

Sume's Video Router docs say higgsfield-genjutsu (Motion Transfer) is listed only when its provider is configured. If the model is missing from GET /v1/video-router/models, a submit for it cannot be treated as a transient error: the id is simply not offered in that runtime. The docs also say to read capabilities from the models endpoint rather than assuming one envelope for every model.

What to do on each side

For provider_capacity_exceeded, wait and retry with the same idempotency key. For provider_not_configured, do not hammer: check the catalog and runtime status first. The error page says the same for job_ledger_not_configured, which you should treat as service unavailable.

• Fetch the model list at startup and when a submit fails with a model error.
• Retry capacity errors with backoff and jitter, not in a tight loop.
• Keep the same Idempotency-Key across the retry.
• Quote the request id when you contact support.

Cap the retries

Neither API gives a retry time for a blocked model on the pages read, so cap your retries and fail the order with a clear message once the cap is reached.