xAI Batch API: 1-год signed URLs і ingest у Bubble через BIAIG

Чому це інший клас ризику

У digest побачив xAI Batch API для Imagine: image generation, image editing, video generation/editing/extension — поруч із chat/Responses. У офіційній документації прямо: signed URLs на результати image/video batch expire через 1 годину; їх треба завантажити одразу. Це не той профіль, про який я писав раніше про OpenAI/Google batch (знижка, async без блокування WU). Тут головна загроза для каталогу — TTL медіа-лінків, а не «довго чекати batch». Поруч із цим: BulkImagen async batches і nano-banana-2-1:.

Є ще шар: у batch metadata — expires_at. Після нього результати batch недоступні. Це окремо від годинного TTL signed URL на конкретний файл.

Що повертає API (коротко)

Створення: POST /v1/batches, додавання рядків POST /v1/batches/{batch_id}/requests, або JSONL через Files API (input_file_id; max 200 MB / 50 000 requests; file-based batch sealed — без пізніх AddBatchRequests).
Статус: GET /v1/batches/{batch_id}; результати посторінково GET .../results (limit до 1000, pagination_token). Кожен рядок мапиться на ваш batch_request_id / custom_id.
Image: image_response — .url, .base64, .usage, .model. Доки дозволяють base64 як альтернативу завантаженню URL.
Video: video_response — .url, .duration, .usage, .model; у batch-доках немає задокументованого .base64 для video — практично лише URL + швидкий download.
JSONL paths з docs: /v1/images/generations, /v1/images/edits, /v1/videos/generations (або /v1/videos), /v1/videos/edits, /v1/videos/extensions. Моделі на кшталт grok-imagine-image-2.0, grok-imagine-video-1.5 — batch підтримка per-model, не універсальна.
Batch completion — best-effort, типово до ~24 год; результати можна читати інкрементально, коли окремі requests завершуються (num_pending не обов’язково нуль).

Конфлікт, який ламає каталоги: batch може «дозрівати» годинами, а signed URL на готовий рядок — ~1 год. Зберігати в Bubble полі «просто URL від xAI» — це биті PDP через добу. Я так не роблю. Поруч із цим: Batch API до 50k запитів.

Ingest-пайплайн для Bubble-каталогу

Публікаційний контекст (не vendor-spec): API Connector для REST xAI + BIAIG як bulk-orchestrator backend workflows — poll, map, persist.

1. API Connector (мінімум контрактів)

Окремі calls або shared collection: create batch, poll status, paginated results (не чекати «batch done» для ingest медіа).
Зберігайте custom_id = stable ключ SKU/variant/job у вашій БД — idempotency при replay.
Не типізуйте «URL назавжди»: response mapping має вести до кроку save, не до фінального Image field каталогу.

2. BIAIG batch-job: poll → ingest до expiry

Так я це будую (methodology, не гарантія SLA xAI):

Після submit batch — recurring backend workflow (cadence під ваш обсяг; Scout не фіксує оптимальний інтервал).
Кожен poll: GET .../results з pagination; для кожного нового batch_request_id:
- Image (flat still для PDP): якщо є image_response.base64 — prefer base64 → Bubble Workflow/Data API { filename, contents, private?, attach_to? } (менше race з TTL). Якщо лише URL — негайно File/Image «save to Bubble storage» (forum/docs pattern через API Connector).
- Image edit leg: той сам ingest на output; input image.url для edit має бути доступний xAI (приватні Bubble-асети — pre-stage у fetchable URL або Files API; batch + file_id input у reviewed docs не підтверджено).
- Video / edit / extension: плануйте streaming download + upload у Storage одразу після появи рядка; великі файли = ризик timeout/partials у вікні 1 год. На base64 не покладайтеся.
Після успішного save — у каталозі зберігайте Bubble file URL / attachment, не xAI signed URL. Статус job: ingested / failed + причина для replay.
Монітор expires_at batch: якщо ingest не встиг — partial loss; потрібен новий batch (sealed JSONL = duplicate spend при операційних помилках). Схожий розбір: Batch-знижка gpt-image-2: unit economics bulk-каталогів.

3. PDP vs bulk: flat stills окремо від edit/video

Leg	Типовий output	Ingest у Bubble
Image generation	url + optional base64	base64 або миттєвий save still
Image edit	url (+ base64?)	output ingest; input URL staging
Video gen/edit/extension	url only	негайний download → Storage; окремі WU/timeout budgets

Для product detail page мені часто вистачає flat still; video — окремий asset type, не той самий workflow без зміни лімітів.

Порівняння з OpenAI batch (контекст, не parity)

OpenAI batch для images часто дає base64 у output JSONL; DALL·E URL outputs теж short-lived (~60 хв). xAI batch акцентує signed media URLs (1 год) + base64 лише для images. Тому «ми вже робили batch ingest для OpenAI» не переноситься 1:1 на video legs xAI — я це перевірив на рівні контракту, не надії.

Назва	Що це / формат	Не для / обмеження
OpenAI batch (images)	Часто base64 у output JSONL
DALL·E URL outputs	URL у output	Short-lived (~60 хв)
xAI batch	Signed media URLs (1 год); base64 лише для images
Перенос ingest	«Ми вже робили batch ingest для OpenAI»	Не 1:1 на video legs xAI (перевірено на рівні контракту)

Відкриті питання (чесно)

Scout packet не закриває:

Коли саме стартує годинний TTL — completion, перший GET results, чи перший fetch URL.
Чи storage_options / Files API persistence (sync Imagine, release notes червня 2026) працює в batch payloads — у reviewed batch docs не задокументовано.
Чи image_response.base64 завжди populated у batch results.
BIAIG-специфіка: cadence poll, concurrency, WU limits, error replay — publication context.

Risk checklist

Dual expiry: signed URL + batch expires_at.
24h batch vs 1h URL — ingest по мірі готовності рядків.
Signed URLs = bearer links; до копії в owned storage — тимчасове публічне exposure.
Video URL-only + розмір файлу.
Edit jobs: input media must be reachable by xAI.
Не зберігати xAI URL у DB як source of truth для каталогу.

Risk item	Ensure / behavior	Pitfall
Dual expiry	Signed URL and batch `expires_at`	Relying on only one expiry
Batch vs URL lifetime	24h batch vs 1h URL; ingest по мірі готовності рядків	Treating batch window like URL lifetime
Signed URLs	Bearer links until copy to owned storage	Ignoring temporary public exposure before owned copy
Video	URL-only delivery + file size constraints	Omitting size or non-URL access assumptions
Edit jobs	Input media reachable by xAI	Media xAI cannot fetch
Catalog source of truth	Owned storage / your records	Не зберігати xAI URL у DB as catalog source of truth

Джерела (межі матеріалу)

Офіційно: Batch API | xAI Docs, Batches REST, Release Notes, Imagine image/video generation pages. Bubble: Bubble API files, forum pattern save URL to storage. Порівняння: OpenAI Batch guide.