СТАТТЯ

BulkImagen batch caps 10/50/100: розмір job і chunking Bubble-каталогу через BIAIG без зайвих batch-id

Віталій Дорошенко Опубліковано

План BulkImagen обмежує не рядки CSV, а total images у POST /v1/batches. Як порахувати chunk з repeating group, зберегти один parent job у Bubble і не ловити 403 batch_limit_exceeded.

Чому це зараз

Я недавно знову наткнувся на це на жовтневому каталозі: repeating group, нормальний обсяг, credits на місці — а submit падає. Не «мало кредитів», а submit time: один POST з завеликим total → HTTP 403 batch_limit_exceeded. У доках це non-retryable. Retry не рятує; chunking має бути до POST.

У pricing BulkImagen це видно явно: Max images/batch — Starter 10, Studio 50, Scale 100, плюс concurrent batches 1 / 10 / 20.

Що саме лімітує API

Ліміт — кількість зображень у одному batch, не «кількість рядків каталогу». Я сам на цьому обпікся: дивишся на rows у CSV і думаєш, що все ок.

Обчислений total у POST https://bulkimagen.com/api/v1/batches залежить від refMode і countPerCombo (1–20):

refMode Формула total (орієнтир)
none або combined ≈ len(prompts) × countPerCombo
each ≈ len(prompts) × len(refImages) × countPerCombo

Я не покладаюся лише на пам’ять про 10/50/100 — на старті run роблю GET /v1/me → limits.maxImagesPerBatch, maxConcurrentBatches, activeBatches.

Приклад (Scale): countPerCombo = 4, refMode = none → максимум ≈ 25 prompt-рядків на один POST (100 ÷ 4). П’ять рядків з countPerCombo = 20 уже дають 100 — row count обманливий.

Credits списуються на створенні batch; статус тягну через GET /v1/batches/{id} до batch.done. API server-to-server only (без CORS) — ключ і POST лишаю у backend/API workflow Bubble (API Connector), не у браузері. Поруч із цим: Фрагментована ніша bulk-tools: Apify spreadsheet.

Bubble: від repeating group / CSV до розміру chunk

Ось як я це збираю в backend workflow:

  1. Збираю рядки каталогу (SKU, template, ref images).
  2. Застосовую SKU/template логіку до chunking: скільки promptів і refImages реально потрапить у batch. Якщо template множить через countPerCombo / refMode each — рахую images, не rows.
  3. maxRowsPerChunk (prompt-рядків на POST):
    • refMode none/combined: floor(maxImagesPerBatch / countPerCombo)
    • refMode each: floor(maxImagesPerBatch / (len(refImages) × countPerCombo)) (якщо refImages однакові для chunk — інакше групую по однаковому fan-out).
  4. Pre-flight: для кожного майбутнього POST рахую total; якщо > maxImagesPerBatch — дрібніший chunk або менший countPerCombo. Про це окремо: Стелю ~500 рядків у bulk-tools.

BIAIG (внутрішній шар оркестрації)

У публічних джерелах BulkImagen/Bubble немає назви «BIAIG» — у цій статті це редакційна модель мого шару: один parent catalog job у Bubble, chunk sub-jobs, список BulkImagen batch id (b_…) з POST, без «зоопарку» непов’язаних id у UI. Поруч із цим: GPT Image 2.5 day-one в.

Мінімальна схема на Thing (parent job):

  • status (draft → chunking → submitting → polling → done / failed)
  • plan_snapshot (з /v1/me на старті run)
  • chunk_size і chunk_count
  • bulkimagen_batch_ids (ordered list)
  • current_chunk_index, опційно last_error_code

Handoff, коли один POST перевищує cap: parent job не шле один великий batch. BIAIG (backend workflow) створює N chunk records або індекс 0…N−1; для кожного — окремий POST з ≤ cap total, append id у список, потім polling по черзі або з урахуванням concurrent limit.

Sequencing і concurrent limits

План maxImagesPerBatch maxConcurrentBatches
Starter 10 1
Studio 50 10
Scale 100 20

На Starter multi-chunk run по суті серіалізується. Я один раз спробував паралельний «Schedule on a list» без контролю — отримав concurrent_limit_exceeded.

Bubble (Manual):

  • Schedule API workflow on a list — з interval для rate limits; interval не гарантує відсутність overlap.
  • Для strict sequential (Starter або свідома черга) — recursive backend workflow: chunk N → POST → poll done → N+1.

Паралельність має сенс лише коли activeBatches + нові POST ≤ maxConcurrentBatches (Studio/Scale).

Чеклист перед production catalog run

  • GET /v1/me → записати maxImagesPerBatch у parent job
  • Формула total для вашого refMode / countPerCombo
  • Chunk boundaries: за prompt rows або за stable catalog keys (SKU id), якщо один рядок fan-out у кілька images — не різати посередині SKU без потреби
  • Баланс credits (402 insufficient_credits) до серії POST
  • Після batch.done — resultUrls public; privacy на Things / у застосунку
  • Не retry на batch_limit_exceeded — зменши chunk

Зв’язок з SKU-template статтею

Templates задають вміст prompt/ref; plan tier задає максимум images на POST. У мене ланцюжок такий: template → fan-out → chunk size → BIAIG parent + ordered b_… ids.

Джерела в Scout packet: bulkimagen.com/pricing, docs/api, llms-full.txt, openapi.json; Bubble Manual — backend workflows, API workflows.

Схожі статті

← Усі статті