Picjam Batch Generation (100+ SKU): an external batch host before Bubble's API Connector and BIAIG

Why this matters now

Two signals landed in the same digest: Picjam Batch Generation (marketing: 100+ SKUs; beta UI: up to 100 products per run) and On-Model Bulk Create (up to 100 products per run; one tag = one job). As a Bubble developer I do not ask which vendor is faster—I ask where the boundary sits: an external batch host (vendor UI or job API) versus orchestrating every SKU inside Bubble via API Connector and BIAIG (job state, SKU↔job_id mapping, PIM/PDP updates). Worth reading next: SynthID Detector goes global: sampling.

I pulled this from public Picjam/On-Model pages plus an internal external batch host + BIAIG template (Ideogram Batch, Batch Banana, bulk-tools ~500-row chunking). It is not verified Bubble product documentation. Same topic: Ideogram Batch (500 rows) vs.

What vendors publish

Picjam

• Batch Generation: wizard flow—product selection, per-SKU styling notes, shared model/background/pose, sample, QA, optional video; catalogue-scale positioning (100–500+ SKUs in marketing copy).
• beta.picjam.ai/batch-upload: explicitly “Select up to 100 products”, beta access code; steps Selected Products → Configure → Generate.
• Pricing: batch generation on Scale (“whole drops”); Studio excludes batch generation.
• API blog (Oct 2026): Bearer auth, garment URL/base64 POST, batch returns job_id, poll or webhook, signed output URLs; contrasts UI limits with “unlimited” API batch size—no public OpenAPI or webhook schemas (Enterprise docs not linked).

Scout uncertainty: digest wording “spreadsheet/SKU batch” is not confirmed as CSV/spreadsheet intake on public pages—only multi-product selection (Shopify import/export on paid tiers is documented elsewhere, not as a spreadsheet-first pipeline).

On-Model

• Bulk Create: up to 100 tags per run, one tag = one job (Flat to Model, Model Swap, Packshot, Garment Recolor); credit estimate in the wizard.
• API: public REST at v2.api.piktid.com—upload, job creation, /jobs/{job_id}/results; webhooks referenced on marketing pages.

Both vendors already do what I often see teams try to rebuild in Bubble: multi-SKU runs, progress, galleries, QA in their UI.

Pipeline comparison

Stage	External batch host (Picjam / On-Model)	Bubble + API Connector + BIAIG
Catalogue input	Vendor UI (~100/run in public Picjam beta; On-Model tags/folders)	Your Bubble/PIM data; editorial pattern: CSV normalization pre-Bubble—not Picjam-documented
Orchestration	Batch Generation / Bulk Create or vendor batch/job API	Per-SKU fan-out in Bubble—risk of timeouts, credits, duplicating vendor Bulk Create
Async	job_id, poll/webhook, signed URLs (Picjam: blog; On-Model: partial public docs)	BIAIG: job records, retries, idempotency, SKU ↔ job_id ↔ asset URL
PDP delivery	Vendor export (ZIP/resizes; Shopify on eligible plans)	Bubble data types, CDN, channels

External batch host means the vendor surface or their async API—not another 100-SKU loop in backend workflows unless Bubble adds catalog truth, chunking beyond 100, or multi-vendor routing.

When Bubble + BIAIG is justified

1. Bubble owns catalog truth (status, channels, approvals); vendors are render engines.
2. Catalogues larger than ~100 per run where the vendor expects repeated UI runs, managed workflows, or API-only orchestration—I centralize chunking (internal ~500-row bulk-tools pattern) and job state in Bubble instead of unbounded parallel API Connector calls.
3. Multi-vendor routing with one BIAIG job model (verify hosts: On-Model brand vs piktid.com API base URL).
4. Post-render workflow Picjam/On-Model QA wizards do not cover.

When not to duplicate the On-Model on-model PDP path

If the goal is a consistent on-model drop with in-vendor QA (model swap, gallery, bulk download), On-Model Bulk Create or Picjam Batch Generation in UI/API is usually enough. I would not rebuild per-SKU orchestration in Bubble that mirrors “one tag = one job” when:

• Bubble is not the system of record;
• I do not need >100 chunking or mixed vendors;
• vendor export (Shopify, ZIP) already closes the loop.

Picjam’s surface area includes more than pure on-model (packshot/ghost/lifestyle/video in product positioning)—I decide overlap by asset type, not by shared “100 SKU” marketing.

Honest constraints

• 100 vs 100+: Picjam beta UI caps at 100; “100+” is marketing—I qualify by tier and access.
• Picjam API notes are marketing content, not a verified spec.
• Shopify paths vary by plan; Scale batch tier may not match Studio+ Shopify assumptions.
• Throughput/QA savings on vendor blogs are promotional, not independently verified.

Pre-integration checklist

• Correct plan (Picjam Scale+)? Beta code for batch-upload?
• SKU source: vendor UI, Shopify, or your CSV (Picjam CSV intake: open question)?
• One batch job vs many POSTs—per-SKU status clarity (weaker publicly for Picjam than On-Model /results)?
• Webhook vs poll in BIAIG; signed URL lifetime.
• Does Bubble belong in the hot path or only post-batch sync?

Check item	What it covers	Notes / gaps
Plan & batch-upload access	Correct plan (Picjam Scale+); beta code for batch-upload	—
SKU source	Vendor UI, Shopify, or your CSV	Picjam CSV intake: open question
Batch job vs many POSTs	One batch job vs many POSTs; per-SKU status clarity	Weaker publicly for Picjam than On-Model /results
Webhook vs poll (BIAIG)	Webhook vs poll in BIAIG	Signed URL lifetime
Bubble in architecture	Whether Bubble belongs in the hot path or only post-batch sync	—

Takeaway

Picjam Batch Generation and On-Model Bulk Create are ready external batch hosts with a similar ~100/run public UI ceiling. I use Bubble API Connector + BIAIG for ingestion, job state, and catalog/PDP—not as a mirror of vendor batch unless I need chunking, multi-vendor logic, or Bubble as source of truth. I treat spreadsheet→CSV→Bubble as a pattern from other briefs; for Picjam I rely on confirmed multi-product, Shopify, and API paths until CSV batch intake is documented. A closer look: ChatGPT is not bulk-native: where.