Mobidoo

벌크 실행

이 문서는 영문 원고를 AI로 번역한 내용이라 표현이 어색할 수 있습니다.

모비두는 라이브 커머스를 두 가지 방식으로 돌립니다. 라이브 커머스 API 페이지는 단일 실행, 클립 타입 경로를 다룹니다. POST …/runs 한 번, opening[] / middle[] / closing[]이 담긴 receipt, 그리고 스레드 기반 클립 재시도입니다.

이 페이지는 다른 쪽, 시트 기반 배치를 다룹니다. 방송 시트의 한 행이 item 하나가 되고, 시트 전체가 POST …/bulk-runs 한 번이 되며, 스키마는 배치가 실제로 쓰는 필드 하나 — full_video — 로 줄어듭니다. 2026-08-28 HBS No.45–65 배치에서 쓴 모양 그대로이며, 백엔드가 같은 본문을 만들 수 있도록 축약 없이 실었습니다.

클립 스키마를 대체하지 않습니다. 타입 있는 클립과 씬 단위 재시도가 필요하면 mobidoo/live-commerce/v1을 계속 쓰세요.

워크스페이스 키

다른 모비두 Format 호출과 같은 규칙입니다. 모비두 팀 워크스페이스 API 키(개인 키가 아니라 모비두 팀에서 만든 키)를 쓰세요. 개인 키로 mobidoo/live-commerce를 호출하면 403 workspace_key_required로 실패합니다 — 팀 Format에는 팀 키가 필요합니다를 참고하세요.

큐를 만들려면 formats:write, 폴링하려면 formats:read가 필요합니다. 기존 키에 스코프를 추가할 수 없으니 새 키를 만드세요.

모비두 워크스페이스에 아직 초대되지 않았다면 Slack에서 허채원 (Chase Huh) 에게 요청하거나 chase@sume.com 으로 요청하세요 — 워크스페이스 접근 권한을 참고하세요.

호출

본문은 파일로 두세요. 행마다 VO가 붙으면 셸 heredoc으로 감당할 크기가 아닙니다.

배치마다 새 Idempotency-Key를 만드세요($(uuidgen)). 이미 쓴 키를 다시 보내면 새 큐가 아니라 예전 큐가 202로 돌아옵니다.

봉투

bulk-runs-body.json은 키 두 개입니다. 나머지는 전부 각 item 안에 있습니다.

2026-08-28 배치는 concurrency: 2 와 item 20개를 보냈습니다. HBS No.45부터 No.65까지이며, No.50은 제외했습니다. 그 행에는 완성된 초안이 없었기 때문입니다. 이런 행은 클라이언트에서 건너뛰세요 — 보낼 "빈 item"은 없습니다. 순서는 제출한 순서 그대로이고 receipt의 items[i].index가 그 위치이니, 시트 행 ↔ index 매핑은 직접 들고 계세요.

create는 frq_… 큐와 함께 202를 반환하고, 첫 concurrency개는 이미 실행 중입니다. 위 배치의 출처: 큐 frq_cfd22d14-68db-4aeb-9816-404a79f0badf, live-commerce v38, create 시점 counts 20 total / 2 running / 18 queued. 그 큐는 만든 키의 소유이므로 여러분 키로는 GET 할 수 없습니다.

봉투 계약 전체, 한도(concurrency 1–16, items 1–100), 큐 receipt 모양, 모든 오류 코드: 대량 실행.

Item 0 — 원본 본문

각 item은 단일 POST …/runs의 본문 그대로입니다. 아래는 item 0(시트 No.45) 그대로이며, communication.webhook_url만 플레이스홀더로 바꿨습니다. 나머지 19개도 같은 키 여섯 개에 각자 행의 데이터가 들어갑니다.

각 키가 하는 일

KeyNotes
instruction산문 + 원본 시트 행. 탭으로 구분된 블록은 시트 줄을 그대로 복사한 것이고, 따옴표 블록은 승인된 VO 전문입니다. 미리 파싱하지 않습니다 — Format이 읽습니다.
input같은 행을 구조화 JSON으로 한 번 더. 백엔드가 Format의 TSV 재파싱에 의존하지 않게 합니다. script.segments는 VO를 컷 단위 객체가 아니라 긴 블록 하나로 담습니다.
output_schemamobidoo/live-commerce/desk-iamdry/v1, strict: false, 필수 필드는 full_video 하나(SumeMediaFile#)입니다. 완성 컷만 발행하는 배치라면 읽지도 않을 클립 배열을 요구할 이유가 없습니다.
primary_output_key"full_video".
generation_spend_cap_usditem당 120 — 큐 전체가 아니라 자식 run 하나의 상한입니다. item 20개는 상한 20개를 쓸 수 있습니다.
communicationitem별 종료 웹훅. 여기서는 https://example.com/hooks/format-run 플레이스홀더로 실었습니다. 여러분 엔드포인트로 바꾸세요.

desk-iamdry/v1은 요청 단위 스키마 이름이지 새 파트너 계약이 아닙니다. 바인딩하면 그 run의 반환 형태만 바뀌고, mobidoo/live-commerce/v1은 그대로입니다.

instruction과 input이 행을 두 번 담는 건 의도적입니다. instruction은 지침, input은 데이터입니다 — Format 호출하기 — 요청 본문을 보고, 크기: 한계가 두 개고, 알려주는 쪽은 하나뿐입니다의 한도를 기억하세요. input은 UTF-8 8 192바이트를 넘으면 거절되고, 각 필드는 약 4 000자까지만 run으로 실려 갑니다. 조용히 잘립니다.

202 이후

  • 큐에는 웹훅이 없습니다. communication.webhook_url은 item별이고, 큐 단위 콜백은 없습니다. 진행 상황은 status_url (GET /v1/format-run-queues/{queue_id})로 폴링하세요.
  • 큐 completed는 "전부 성공"이 아닙니다. 모든 item이 종료됐다는 뜻입니다. counts.failed와 counts.canceled로 분기하세요.
  • 실패 원인은 자식에서 읽으세요. items[i].run_id로 GET /v1/format-runs/{run_id}를 부르세요. 큐 item에는 거친 format_run_failed만 있습니다.
  • 자식은 평범한 Format run이라서 약한 행 하나는 previous_run_id로 자기 스레드에서 손볼 수 있습니다. 단 클립 스키마를 바인딩한 본문일 때만입니다. full_video 하나만 받으면 지목할 씬 id가 없습니다.

다음