Picjam Batch Generation (100+ SKU): зовнішній batch-host перед Bubble API Connector і BIAIG

Навіщо зараз

У digest з’явилися два близькі сигнали: Picjam Batch Generation (маркетинг — 100+ SKU, beta UI — до 100 продуктів за run) і On-Model Bulk Create (до 100 products/run, один tag = одна job). Я Bubble-розробник, і мене цікавить не «хто швидший», а де проходить межа: зовнішній batch-host (vendor UI або їхній job API) проти fan-out у Bubble через API Connector і BIAIG (job state, мапінг SKU↔job_id, оновлення PIM/PDP). Про це окремо: FLORA: spreadsheet batch через MCP.

Текст спирається на публічні сторінки Picjam/On-Model і на внутрішній шаблон «external batch host + BIAIG» (Ideogram Batch / Batch Banana / bulk-tools ~500 рядків). Це не верифікована документація Bubble. Схожий розбір: Ideogram Batch (500 rows) проти.

Що публічно описують vendor’и

Picjam

• Batch Generation (blog + homepage): wizard — вибір продуктів, styling notes на SKU, спільні model/background/pose, sample, QA, опційно video; позиціонування для цілих дропів (100–500+ SKU в маркетингу).
• beta.picjam.ai/batch-upload: явно «Select up to 100 products», access code; кроки Selected Products → Configure → Generate.
• Pricing: batch generation — на Scale («whole drops»); Studio batch не включає.
• API blog (Oct 2026): Bearer key, POST з garment URL/base64, batch повертає job_id, poll або webhook, signed URLs; заявлено контраст UI limit vs «unlimited» API batch — без публічного OpenAPI і webhook schema (Enterprise docs не в відкритому доступі).

Uncertainty (Scout): digest «spreadsheet/SKU batch» у публічних джерелах не підтверджує CSV/spreadsheet intake — лише multi-product selection (і Shopify import на paid tiers, не як документований CSV pipeline).

On-Model

• Bulk Create: до 100 tags/run, one tag = one job (Flat to Model, Model Swap, Packshot, Garment Recolor); credit preview у wizard.
• API: публічний REST на v2.api.piktid.com — upload → file_id → start job → /jobs/{job_id}/results; webhooks згадані на marketing-сторінках.

Обидва vendor’и вже роблять те, що в Bubble я часто бачу як спробу «перебудувати»: multi-SKU run, progress, галерея, QA в їхньому UI.

Pipeline для порівняння

Крок	Зовнішній batch-host (Picjam / On-Model)	Bubble + API Connector + BIAIG
Вхід каталогу	Vendor UI (до ~100/run у публічному UI Picjam; On-Model — tags/folders)	Ваш PIM/Repeating Group; редакційний патерн: нормалізація CSV перед Bubble — не Picjam-documented
Batch orchestration	Vendor Batch Generation / Bulk Create або їхній batch/job API	Fan-out POST на SKU — ризик timeout, credits, дублювання vendor Bulk Create
Async	job_id, poll/webhook, signed URLs (Picjam — blog; On-Model — docs частково)	BIAIG: стан job, retry, idempotency, зв’язок SKU ↔ job_id ↔ asset URL
Вихід на PDP	Export (Picjam — ZIP/platform resize; Shopify на планах)	Запис у Bubble data types, CDN, канали

Межа «зовнішній batch-host»: vendor platform або їхній documented/async API — не «ще один 100-SKU loop» у Backend workflow, якщо він лише повторює Bulk Create/Batch Generation без додаткової цінності.

Коли Bubble + BIAIG має сенс

1. Bubble — source of truth для SKU, статусів, каналів; vendor лише render engine.
2. Каталог >100 за run і vendor очікує повторні UI runs, managed service або API-only — тоді chunking (~500 рядків у bulk-tools шаблоні) і централізований job state у Bubble, а не сотні паралельних API Connector calls без черги.
3. Multi-vendor routing (Picjam для одного дропу, On-Model для model swap) — одна BIAIG-модель jobів, різні base URL (перевіряйте auth/host: On-Model brand vs piktid.com API).
4. Downstream: оновлення PDP, approval, локалізація — те, чого немає в vendor QA wizard.

Коли не дублювати On-Model on-model PDP сценарій

Якщо ціль — консистентний on-model drop з QA в vendor (Flat to Model / Model Swap, gallery, bulk download), On-Model Bulk Create або Picjam Batch Generation у їхньому UI/API зазвичай достатньо. Я не будував би в Bubble per-SKU orchestration, що дзеркалить «one tag = one job», якщо:

• немає власного catalog truth у Bubble;
• немає потреби в chunking >100 або змішаних vendor’ів;
• Picjam/On-Model уже закривають QA і export на Shopify/ZIP.

Picjam ширший за чистий on-model (packshot/ghost/lifestyle/video у продуктовому позиціонуванні) — overlap з On-Model PDP визначаю по типу asset на workflow, не по marketing «100 SKU».

Практичні обмеження (не hype)

• 100 vs 100+: beta UI Picjam — 100; marketing 100+ — не ототожнюю без уточнення tier/access.
• Picjam API деталі — marketing blog, не spec; «unlimited» API batch може суперечити UI на Enterprise docs.
• Shopify import/export залежить від plan; batch (Scale+) ≠ автоматично той самий Shopify path, що Studio+.
• Промо-claims throughput/QA — не незалежно верифіковані.

Checklist перед інтеграцією

• Batch на потрібному plan (Picjam Scale+)? Beta access для batch-upload?
• Джерело SKU: vendor UI, Shopify, чи ваш CSV (для Picjam CSV — open question)?
• Один API batch job vs 100 окремих POST — що повертає per-SKU status (Picjam — менш ясно публічно, ніж On-Model /results)?
• Webhook vs poll у BIAIG; signed URL expiry і re-fetch.
• Чи потрібен Bubble взагалі в hot path, чи лише post-batch sync?

Тема	Що перевірити	Нюанс
Batch / plan	Batch на потрібному plan (Picjam Scale+); beta access для batch-upload	—
Джерело SKU	Vendor UI, Shopify, чи ваш CSV	Для Picjam CSV — open question
Batch vs окремі POST	Один API batch job vs 100 окремих POST	Що повертає per-SKU status; Picjam — менш ясно публічно, ніж On-Model /results
BIAIG доставка	Webhook vs poll	Signed URL expiry і re-fetch
Bubble	Чи потрібен у hot path	Чи лише post-batch sync

Висновок

Picjam Batch Generation і On-Model Bulk Create — готові зовнішні batch-host’и з подібним UI ceiling ~100/run. Bubble API Connector + BIAIG я тримаю як шар ingestion, job state і catalog/PDP, а не заміну vendor batch, якщо я не додаю chunking, multi-vendor або власний source of truth. Spreadsheet→CSV→Bubble — корисний редакційний патерн з інших brief’ів; для Picjam покладаюся лише на підтверджений multi-product/Shopify/API шлях, доки CSV intake не задокументований.