You have already chosen a BACH native video API endpoint. Then you notice another model-branded experience on the BACH platform—or open the Text to Video documentation and see: ```json { "model_name": "" } ``` The natural question is: > What should actually go into `model_name`? The answer should come from the request schema for the exact endpoint you are calling, not from a model label visible elsewhere on the platform. ```text PLATFORM MODEL AVAILABILITY ≠ ENDPOINT model_name ENUM ``` And: ```text PLACEHOLDER ≠ OPEN MODEL CATALOG ``` This guide builds a **MODEL ROUTING RECORD** so you can separate an endpoint’s documented API contract from Web product labels, placeholders, and other model-branded surfaces. **Quick Answer** | Question | Current documented answer | | ------------------------------------------------------------------------------------------- | ---------------------------------------------------- | | Does Text to Video expose `model_name`? | Yes | | Is `model_name` required? | No | | Documented default | `bach-1.0` | | Documented enum | `bach-1.0` | | Image to Video contract | Same | | Reference to Video contract | Same | | Montage contract | Same | | Why does T2V show ``? | It is an example placeholder | | Does `` expand the enum? | No | | Is Seedance visible elsewhere on BACH? | Yes, as a separate Web/product surface | | Is Seedance documented as a `model_name` on the reviewed four native-video sheets? | **No** | | Was a current first-party Seedance API create sheet identified in the reviewed public docs? | **No** | | Does query success document which model ran? | **No model-identity field documented** | | Does the success callback document which model ran? | **No model-identity field documented** | | Should a Web model label be copied into `model_name`? | **Only if the exact API sheet documents that value** | The central rule is: > **The endpoint request sheet controls the documented API value. Platform visibility does not expand its enum.** **What the Four Current Native-Video Sheets Document for `model_name`** The reviewed current BACH native-video request sheets expose the same `model_name` contract. | Endpoint | `model_name` documented? | Required | Default | Enum | Official example | | ------------------------------------------------------------------------- | -----------------------: | -------: | ---------- | ---------- | ---------------- | | [Text to Video](https://www.bach.art/docs/videos/v1/text2video) | Yes | No | `bach-1.0` | `bach-1.0` | `` | | [Image to Video](https://www.bach.art/docs/videos/v1/image2video) | Yes | No | `bach-1.0` | `bach-1.0` | `bach-1.0` | | [Reference to Video](https://www.bach.art/docs/videos/v1/reference2video) | Yes | No | `bach-1.0` | `bach-1.0` | `bach-1.0` | | [Montage](https://www.bach.art/docs/videos/v1/montage) | Yes | No | `bach-1.0` | `bach-1.0` | `bach-1.0` | So, on these four reviewed endpoints: ```text model_name → optional → default bach-1.0 → documented enum bach-1.0 ``` That does not mean every BACH API uses `model_name` or supports only `bach-1.0`. Other API families use different request surfaces. The important scope is narrower: > **On the reviewed Text to Video, Image to Video, Reference to Video, and Montage request sheets, `bach-1.0` is the documented `model_name` enum value.** **Omitting `model_name` vs Explicitly Sending `bach-1.0`** Because the field is optional, the current request contract distinguishes two documented request forms. **Omit the field** ```text model_name omitted → documented default = bach-1.0 ``` **Send the documented enum explicitly** ```json { "model_name": "bach-1.0" } ``` The reviewed pages do not publish an additional difference in: * Generation quality * Pricing * Priority * Routing * Reproducibility * Backend version pinning So do not turn the explicit form into claims such as: ```text explicit bach-1.0 → stronger reproducibility ``` Or: ```text omitted model_name → automatic best-model routing ``` Those behaviors are not part of the reviewed contract. **Why Text to Video’s `` Does Not Mean “Any Model”** Text to Video is the potentially confusing case. Its current field definition documents: ```text model_name Required: No Default: bach-1.0 Enum: bach-1.0 ``` But the official request example uses: ```json { "model_name": "" } ``` That placeholder does not override the field definition. ```text EXAMPLE PLACEHOLDER ≠ ENUM EXPANSION ``` Image to Video, Reference to Video, Montage, and the General Guide’s sample request use the concrete value: ```json { "model_name": "bach-1.0" } ``` So the safe reading is: > **Treat `` as an example placeholder. The enum on the same endpoint page defines the documented request value.** It should not be treated as permission to substitute an arbitrary model or partner string. **A Model Visible on BACH Web Is Not Automatically a Native-Video API Value** BACH can expose multiple model-branded product experiences without adding all of those labels to every API endpoint. For example, BACH currently exposes a separate [Seedance Web create surface](https://www.bach.art/create/seedance): ```text SEEDANCE → visible as a separate BACH product experience ``` It does not establish: ```text SEEDANCE → valid model_name on /videos/text2video ``` The reviewed native-video API sheets still document: ```text model_name enum → bach-1.0 ``` No current first-party Seedance API create sheet was identified in the reviewed public documentation. Therefore, this guide does not treat a Seedance Web label as a documented `model_name` value for the reviewed native-video endpoints. ```text PRODUCT LABEL ≠ API WIRE IDENTIFIER ``` Do not infer values such as: ```json { "model_name": "seedance-2.5" } ``` Or: ```json { "model_name": "SEEDANCE 2" } ``` Unless the exact API endpoint documentation explicitly publishes that identifier. This does not mean Seedance is unavailable through every possible BACH integration surface. It only means those identifiers are not documented on the four native-video request sheets reviewed here. **Different BACH API Families Can Represent Model Identity Differently** `model_name` is not a universal field across every BACH API family. | API family | Current documented model-selection surface | | ------------------ | ------------------------------------------ | | Text to Video | `model_name` | | Image to Video | `model_name` | | Reference to Video | `model_name` | | Montage | `model_name` | | Text to Image | No documented `model_name` field | | Text to Subject | No documented `model_name` field | That means this pattern is unsafe: ```text I saw a model name somewhere on BACH ↓ therefore every BACH API must accept it through model_name ``` Instead: ```text IDENTIFY API FAMILY ↓ OPEN THAT FAMILY'S REQUEST SHEET ↓ USE ITS DOCUMENTED CONTRACT ``` The native-video `model_name` field should not be copied into another API family unless that family documents it. **Query and Callback Do Not Document Which Model Ran** The reviewed current video query-success schemas document fields such as: ```text task_id status created_at started_at completed_at video_url ``` They do not document a model-identity field such as: ```text model model_name model_version provider engine ``` The current [Video Task Success Callback](https://www.bach.art/docs/v1/callbacks) similarly documents: ```text task_id status video_url ``` Without a documented model-identity field. So this workflow is not supported by the reviewed response contract: ```text query task ↓ read which model ran ``` More precisely: > **The reviewed current query-success and callback schemas do not document the executing model identity as a returned field.** That does not establish what information may exist internally. It only describes the documented API response surface. **If You Were About to Copy a Web Label Into the Request Body** The following is a client-side integration check, not a documented BACH error-cause tree. **1. Identify the exact API endpoint** For example: ```text /videos/text2video /videos/image2video /videos/reference2video /videos/montage ``` **2. Open that endpoint’s current request sheet** Record: ```text model_name documented? required? default? enum? ``` **3. Inspect the serialized JSON actually being sent** Do not rely only on what your application code was intended to produce. **4. Compare `model_name` with the documented enum** For the reviewed current native-video endpoints: ```text documented enum → bach-1.0 ``` **5. If the serialized body contains a Web or product label** For example, a Seedance label or another guessed partner identifier, the safe conclusion is: > The submitted value is not part of the reviewed endpoint’s documented enum. That does not establish exactly how the server will handle the value. Do not claim: ```text unlisted value → always HTTP 404 ``` Or: ```text unlisted value → automatically falls back to bach-1.0 ``` Or: ```text unlisted value → silently ignored ``` Unless BACH publishes that behavior. **What About Invalid or Non-Existent Models?** Current [BACH Error Codes](https://www.bach.art/docs/v1/error) note that some non-existent-model paths can use business code `1000` with HTTP `404`. That does not establish a universal invalid-`model_name` rule for the reviewed native-video endpoints. | Question | Current reviewed status | | ---------------------------------------------------- | ----------------------- | | Unknown native-video model always returns `1000` | **Not documented** | | Unknown native-video model always returns HTTP `404` | **Not documented** | | Exact universal invalid-`model_name` message | **Not documented** | | Unknown value falls back to `bach-1.0` | **Not documented** | | Unknown value is ignored | **Not documented** | | Automatic partner-model routing | **Not documented** | | Model aliases | **Not documented** | So the practical action remains: ```text READ ENDPOINT SCHEMA ↓ INSPECT SERIALIZED BODY ↓ COMPARE REQUEST VALUE WITH DOCUMENTED ENUM ``` Rather than guessing server behavior. **`bach-1.0` Is a Documented Request Value, Not an Immutable-Version Guarantee** The current native-video request sheets document: ```text bach-1.0 ``` As the `model_name` value. That establishes an API identifier. It does not, from the reviewed documentation, establish: * An immutable checkpoint * A specific backend build hash * A permanent weights snapshot * A semantic-version SLA * Reproducibility across all future dates So this distinction is useful: ```text DOCUMENTED API ENUM VALUE ≠ IMMUTABLE BACKEND VERSION GUARANTEE ``` Do not infer version-pinning behavior that the request documentation does not publish. **Build a MODEL ROUTING RECORD** When you need to choose or verify a BACH model value, record the following. **1. Exact endpoint** Which API route are you calling? **2. API family** For example: ```text native video Text to Image Text to Subject other ``` **3. Does the request sheet expose `model_name`?** For the reviewed native-video sheets: ```text YES ``` For the current Text to Image and Text to Subject sheets: ```text NO DOCUMENTED FIELD ``` **4. Is `model_name` required?** For the reviewed native-video sheets: ```text NO ``` **5. Documented default** ```text bach-1.0 ``` **6. Documented enum** ```text bach-1.0 ``` **7. Official example value** Text to Video: ```text ``` Evidence class: ```text EXAMPLE PLACEHOLDER ``` Image to Video, Reference to Video, Montage, and the General sample: ```text bach-1.0 ``` **8. Did the intended model value come from a Web/product label?** Label that as: ```text PRODUCT-SURFACE OBSERVATION ``` Not: ```text API CONTRACT ``` **9. Does the exact endpoint sheet document that identifier?** If not: ```text DO NOT TREAT IT AS A DOCUMENTED REQUEST VALUE ``` **10. Is a first-party API sheet for the partner model identified?** For Seedance in the reviewed public documentation: ```text NOT IDENTIFIED ``` **11. Is that partner identifier documented on the reviewed native-video sheets?** ```text NOT ON THE REVIEWED FOUR ENDPOINT SHEETS ``` **12. Does query success document model identity?** ```text NOT DOCUMENTED ``` **13. Does success callback document model identity?** ```text NOT DOCUMENTED ``` **14. Is unknown-model behavior fully documented?** ```text NO ``` More precisely: ```text ONLY PARTIAL ERROR-CODES CONTEXT IS PUBLISHED ``` **15. Is Web-to-API model mapping verified?** ```text NOT VERIFIED ``` **16. Safe action** ```text READ THE EXACT ENDPOINT ENUM ↓ COMPARE THE SERIALIZED REQUEST ↓ USE DOCUMENTED REQUEST VALUES ``` **The Request Schema, Not the Platform Catalog, Controls the API Value** The practical workflow is: ```text I ALREADY CHOSE AN API ENDPOINT ↓ I WANT TO SPECIFY A MODEL ↓ OPEN THAT ENDPOINT'S REQUEST SHEET ↓ CHECK model_name ↓ READ DEFAULT + ENUM ↓ INSPECT SERIALIZED JSON ↓ COMPARE REQUEST VALUE WITH ENUM IF THE VALUE CAME FROM A WEB / PRODUCT LABEL → DO NOT ASSUME IT IS AN API IDENTIFIER IF T2V SHOWS → READ THE FIELD DEFINITION → DO NOT TREAT THE PLACEHOLDER AS AN OPEN CATALOG ``` The central distinction is: ```text PLATFORM MODEL AVAILABILITY ≠ ENDPOINT model_name ENUM ``` And: ```text WEB PRODUCT LABEL ≠ API WIRE IDENTIFIER ``` **API and Web Model Selection Are Separate Surfaces** This guide covers the documented BACH API model-selection surface. Current BACH Web pages are useful evidence that the platform can expose separate model-branded experiences, but Web-to-API request-body mapping was not independently verified. Therefore: ```text WEB MODEL SELECTOR ≠ DOCUMENTED API ENUM ``` Unless the API documentation explicitly establishes that mapping. **FAQ** **What `model_name` does current BACH Text to Video document?** The reviewed current Text to Video sheet documents `bach-1.0` as the default and enum value. **Is `model_name` required?** No. It is optional on the reviewed Text to Video, Image to Video, Reference to Video, and Montage create sheets. **What happens if I omit `model_name`?** The documented default on those four sheets is `bach-1.0`. **Why does Text to Video show ``?** It appears as an example placeholder. The same page still documents `bach-1.0` as the enum. **Does `` mean any model string is valid?** No. The placeholder does not expand the field’s documented enum. **Can I replace `` with Seedance?** Not based on the reviewed current native-video request sheets. **Is Seedance available on BACH?** BACH exposes a separate Seedance Web product surface. That does not automatically make a Seedance label a native-video API `model_name`. **Is there a current BACH Seedance API create sheet?** No current first-party Seedance API create sheet was identified in the reviewed public documentation. **Does an unknown model fall back to `bach-1.0`?** That behavior is not documented. **Does an unknown model always return `1000` or HTTP `404`?** No universal rule of that kind is documented for the reviewed native-video endpoints. **Does query success tell me which model ran?** The reviewed current query-success schemas do not document a model-identity field. **Does the success callback tell me which model ran?** The reviewed callback success schema does not document a model-identity field. **Do all BACH APIs use `model_name`?** No. Current Text to Image and Text to Subject request sheets do not document that field. **Does explicitly sending `bach-1.0` pin an immutable backend model version?** No such immutable-checkpoint or version-pinning guarantee was identified in the reviewed request documentation. **Are Web model labels guaranteed to equal API identifiers?** No such Web-to-API mapping was independently verified. **Review the Exact BACH Video Create Sheet You Are Calling** Before choosing a model string, start with the request contract for the exact endpoint: * [Text to Video](https://www.bach.art/docs/videos/v1/text2video) * [Image to Video](https://www.bach.art/docs/videos/v1/image2video) * [Reference to Video](https://www.bach.art/docs/videos/v1/reference2video) * [Montage](https://www.bach.art/docs/videos/v1/montage) Supporting reference: * [BACH API General Guide](https://www.bach.art/docs/v1/general) If your question is specifically about the Seedance Web product rather than the native-video `model_name` field: * [BACH Seedance Create Surface](https://www.bach.art/create/seedance) The rule remains simple: > **On the reviewed native-video endpoints, the request sheet—not the platform model catalog—defines the documented `model_name` value. A Web label or example placeholder does not expand that enum unless the endpoint documentation explicitly does so.**

BACH API model_name: How to Read Native Video Model Enums When the Web Shows Other Models

How to Turn Product Photos Into AI UGC Ads Without Filming a Creator

123How to Turn an Existing Static Ad Into AI Video Variations

It Works in BACH Web—Can You Reproduce the Same Workflow Through the API?