You already have an authorized BACH `AccessKey` and `SecretKey`. Those credentials are not the value you send directly in the `Authorization` header. The current BACH API General Guide documents a signed-token flow: ```text AccessKey + SecretKey ↓ HS256 JWT ↓ API_TOKEN ↓ Authorization: Bearer ↓ BACH API REQUEST ``` The practical job is therefore not simply “add a Bearer token.” You need to know: * What role the AccessKey and SecretKey play * How the documented JWT example is constructed * Which values are examples rather than fixed BACH policy * Where the SecretKey should live * What authentication codes 1100 through 1103 tell you when a request returns HTTP 401 This guide starts after you already have an authorized AccessKey and SecretKey. It does not document credential issuance, choose a generation mode, upload files, or manage generation results. **Quick Answer** | Layer | Current BACH role | | ------------- | ------------------------------------------------ | | AccessKey | Used as `iss` in the documented JWT example | | SecretKey | Signs the HS256 JWT; keep it server-side | | `API_TOKEN` | Generated JWT sent with the API request | | Authorization | `Bearer ` | | 1100 | Token, signature, issuer/key, or parsing problem | | 1101 | Authorization missing or empty | | 1102 | `nbf` has not yet become valid | | 1103 | `exp` has already passed | The current Python example uses an `nbf` value about five seconds before issuance and an `exp` value about ten days after issuance. Those are documented example values. They are not, on the reviewed Authentication surface, published as a universal five-second clock-skew requirement or a mandatory ten-day BACH token lifetime. **Why BACH Authentication Fits This Integration** Current BACH General documentation does not treat AccessKey or SecretKey as the request Bearer value. Instead, it generates `API_TOKEN` as a JWT using the HS256 signing algorithm and following RFC 7519. The documented Python example: * Sets `iss` to the AccessKey * Includes `nbf` * Includes `exp` * Signs the JWT with the SecretKey BACH also recommends generating the token on your server so the SecretKey is not exposed in browsers, mobile clients, or public repositories. The resulting token is then sent as: ```text Authorization: Bearer ``` Current BACH Error Codes distinguish four authentication-specific failures: ```text 1101 → Authorization header problem 1100 → token validation problem 1102 → token is not valid yet 1103 → token has expired ``` That combination—JWT minting, SecretKey placement, request formatting, and authentication-code diagnosis—is the useful integration workflow. **Your AccessKey and SecretKey Are Not the Request Token** The starting credentials and the request token have different roles. ```text AccessKey + SecretKey ↓ JWT GENERATION ↓ API_TOKEN ``` The request then carries: ```text Authorization: Bearer ``` Not: ```text Authorization: Bearer ``` and not: ```text Authorization: Bearer ``` In the documented example, the AccessKey participates in the JWT payload while the SecretKey signs the token. The generated JWT is the `API_TOKEN` that belongs in the request header. **Mint an HS256 JWT** The current BACH API General Guide states that `API_TOKEN` is generated from an AccessKey and a SecretKey. The JWT uses: ```text HS256 ``` and follows: ```text RFC 7519 ``` The documented example header is: ```json { "alg": "HS256", "typ": "JWT" } ``` The documented Python example uses a payload shaped like: ```python payload = { "iss": ak, "nbf": int((now - timedelta(seconds=5)).timestamp()), "exp": int((now + timedelta(days=10)).timestamp()), } ``` and signs it using the SecretKey: ```python jwt.encode( payload, sk.encode("utf-8"), headers=headers ) ``` The important role mapping is: | JWT element | Role in the documented example | | ----------------- | -------------------------------------------------- | | `iss` | AccessKey | | `nbf` | Time before which the token should not be accepted | | `exp` | Expiration time | | HS256 signing key | SecretKey | The Python-specific `encode("utf-8")` expression belongs to the implementation example. It should not be turned into a language-independent BACH API field. Likewise, the reviewed BACH example does not establish additional required claims such as `aud`, `sub`, `iat`, `jti`, or `kid`. **The Five-Second `nbf` and Ten-Day `exp` Are Example Values** This distinction matters. **`nbf`** The documented Python example uses an `nbf` value approximately: ```text now - 5 seconds ``` Current Error Code 1102 shows that BACH evaluates `nbf`: if the token’s not-before time has not yet arrived, authentication can fail. What the documentation does not establish is a universal rule saying: > Every BACH token must set `nbf` exactly five seconds in the past. The five-second offset is part of the current example implementation. **`exp`** The same example sets: ```text exp = now + 10 days ``` Current Error Code 1103 shows that BACH evaluates expiration: a token whose `exp` is already in the past is rejected. But the reviewed Authentication surface does not publish ten days as: * A mandatory token lifetime * A maximum token lifetime * A default platform TTL The accurate wording is: > The current Python example chooses a ten-day expiration. Not: > BACH tokens expire every ten days. BACH does evaluate `nbf` and `exp`: current Error Codes distinguish a token whose `nbf` has not yet arrived from one whose `exp` has already passed. The reviewed documentation does not prescribe a required timezone or a universal five-second skew value. **Generate `API_TOKEN` on Your Server** SecretKey placement is not just an implementation detail. Current BACH Security Recommendations say not to expose the SecretKey in: * Browsers * Mobile clients * Public repositories They recommend generating the token on your server and having the server make requests to the BACH API. The intended boundary is therefore: ```text SERVER ├─ AccessKey ├─ SecretKey ├─ Mint API_TOKEN └─ Call BACH API ``` not: ```text BROWSER / MOBILE CLIENT └─ SecretKey ``` When a new token is needed, mint a new `API_TOKEN` from valid AccessKey and SecretKey credentials. The reviewed General Authentication and Error Codes surfaces do not document: * An OAuth flow * A refresh-token endpoint * A token-revocation endpoint * A key-rotation API * A SecretKey recovery workflow This guide therefore does not infer those systems. **Send `Authorization: Bearer ` With Exactly One Space** The documented request convention is: ```text Authorization: Bearer ``` The General Guide and multiple inspected BACH endpoint pages specify that there should be exactly one space between: ```text Bearer ``` and: ```text ``` BACH’s General Security Recommendations also list Bearer spacing among the first checks when authentication fails. Error Code 1101 covers cases where `Authorization` is missing, empty, or contains an empty Bearer prefix. The Error Codes surface also contains language about bare-token acceptance. However, the documented General Guide and endpoint request examples consistently use: ```text Authorization: Bearer ``` That is the request convention this guide follows. **HTTP 401 Is Not One Authentication Failure** A BACH HTTP 401 does not automatically mean: > The token expired. Current Error Codes distinguish several authentication failures underneath the HTTP status. | Business code | What failed | First thing to inspect | | ------------- | ------------------------------------------------------------------------- | -------------------------------------------------- | | 1100 | Token malformed, signature invalid, issuer/key invalid, or parsing failed | JWT construction, credentials, and token integrity | | 1101 | Authorization missing or empty | Request header | | 1102 | `nbf` has not yet arrived | Client clock and token timing | | 1103 | `exp` has passed | Generate a new token | The useful flow is: ```text HTTP 401 ↓ READ BACH BUSINESS CODE ├─ 1101 → HEADER ├─ 1100 → TOKEN VALIDATION ├─ 1102 → NOT YET VALID └─ 1103 → EXPIRED ``` Use the returned business code rather than assuming one cause for every 401. **What Error 1100 Means** 1100 points to a problem validating the token itself. The current Error Codes include cases such as: * Malformed token * Invalid signature * Invalid issuer or key * Token parsing failure A useful summary is: > 1100 means the token could not be validated successfully. Relevant checks include the credentials used to mint it, the JWT-signing process, and whether the token was truncated or modified before reaching BACH. This is still an authentication problem. It should not be expanded into general generation-error troubleshooting. **What Error 1101 Means** 1101 is different. It points to the `Authorization` layer rather than the contents of an otherwise present token. Current cases include: * Missing `Authorization` * Empty `Authorization` * An empty Bearer prefix Think of the distinction as: ```text 1101 → HEADER PROBLEM ``` versus: ```text 1100 → TOKEN VALIDATION PROBLEM ``` Follow the documented request format: ```text Authorization: Bearer ``` with a non-empty token. **What Error 1102 Means** 1102 means the token’s: ```text nbf ``` time has not yet arrived. Current Error Codes direct attention to the client clock and token timing. Depending on the situation, the documented actions include calibrating the client clock, waiting until the token becomes valid, or issuing a new token. This does not mean the correct universal solution is: > Always subtract exactly five seconds. The five-second offset belongs to the current Python example, not a published global BACH rule. **What Error 1103 Means** 1103 means the token is already past: ```text exp ``` The authentication material is expired. The relevant action is to generate a new token. Again, this should not be converted into: > BACH tokens expire every ten days. The ten-day value is the current example’s chosen expiration window. **Do Not Automatically Retry the Same Authentication Failure** Current BACH Error Codes guidance says authentication failures should not be automatically retried as-is. Repeatedly sending the same: * Missing header * Malformed token * Future-`nbf` token * Expired token does not repair the authentication layer. Correct the header or authentication material first. This is intentionally narrower than a general API retry guide. Other failure classes belong to separate troubleshooting workflows. **The Same Authorization Convention Applies Across the Inspected BACH APIs** The authentication layer is shared even though downstream request bodies differ. | BACH surface | Current documented authentication | | ------------------ | ----------------------------------------------- | | Text to Video | `Bearer ` | | Image to Video | `Bearer ` | | Reference to Video | `Bearer ` | | Montage | `Bearer ` | | Text to Image | Bearer Token; examples use `Bearer ` | | Text to Subject | `Bearer ` | | File Uploads | `Bearer ` | This does not mean those endpoints share the same generation or upload schema. Authentication is only the shared request-access layer. For File Uploads behavior, use the current BACH File Uploads documentation. For asynchronous video-result delivery, use BACH Callbacks. If you are still choosing which BACH video workflow to use, that is a separate production decision. **A 403 `Access denied` Is Not the Same as These 401 Token Errors** The current Error Codes surface also documents an HTTP 403 `Access denied` case involving geo/source-IP/AccessKey access checks. That is a different class from the HTTP 401 authentication failures covered here. Do not interpret: ```text 403 Access denied ``` as automatically meaning: ```text invalid JWT signature ``` Likewise, this article does not document how to administer an AccessKey allowlist because the reviewed Authentication surface does not provide a complete allowlist-management workflow. **This Guide Starts After You Already Have Credentials** The current General Authentication page expects the developer to enter an existing: ```text AccessKey ``` and: ```text SecretKey ``` It does not, on the reviewed surface, document a complete workflow for: * Creating credentials * Rotating them * Revoking them * Recovering a SecretKey * Managing multiple keys The presence of a Go to Console link is not enough to infer those steps. For that reason, this guide starts once authorized credential material already exists. **Build an Authentication Record** Before sending production requests, build a compact authentication record. 1. **Start with existing credentials** You already have: ```text AccessKey SecretKey ``` 2. **Keep SecretKey server-side** Do not put it in: ```text browser mobile client public repository ``` 3. **Build the JWT** Current documented method: ```text HS256 RFC 7519 ``` The current example includes: ```text iss nbf exp ``` 4. **Sign with SecretKey** The generated JWT becomes: ```text API_TOKEN ``` 5. **Send the documented request header** ```text Authorization: Bearer ``` with exactly one space after `Bearer`. 6. **If HTTP 401 appears, inspect the BACH business code** ```text 1101 → Authorization header 1100 → token validation 1102 → nbf timing 1103 → expiration ``` 7. **Fix authentication before retrying** Do not keep sending the same invalid authentication material unchanged. **API and Web Are Separate Evidence Surfaces** This guide follows the documented BACH API Authentication surface. A matching consumer-Web credential-management interface was not independently verified. This article therefore does not invent: * A Web JWT generator * An API-key dashboard * Credential-rotation controls * SecretKey recovery * Web/API parity For the current authentication method and Python example, use the BACH API General Guide. For authentication-specific business codes, use BACH Error Codes. **FAQ** **Is my AccessKey the BACH API token?** No. Current BACH documentation generates `API_TOKEN` as a JWT from the AccessKey and SecretKey. **Should I put SecretKey in the `Authorization` header?** No. The documented request header contains the generated: ```text API_TOKEN ``` not the SecretKey. **Which JWT algorithm does BACH document?** The current General Authentication surface documents HS256 and references RFC 7519. **Does BACH require a ten-day token lifetime?** The reviewed Python example sets `exp` approximately ten days ahead. The current Authentication surface does not publish ten days as a universal mandatory or maximum token lifetime. **Must I set `nbf` exactly five seconds in the past?** No such universal requirement is documented. The current Python example uses approximately a five-second offset, while Error Code 1102 establishes that `nbf` itself is evaluated. **Where should I generate `API_TOKEN`?** Current BACH documentation recommends generating the token on your server and keeping SecretKey out of browsers, mobile clients, and public repositories. **What does BACH error 1100 mean?** 1100 means the token could not be validated because of issues such as malformed token structure, signature validation, issuer/key validation, or parsing. **What does BACH error 1101 mean?** 1101 points to a missing or empty `Authorization` value. Check the request header and use the documented: ```text Authorization: Bearer ``` format. **What is the difference between 1102 and 1103?** 1102 means the token is not valid yet because `nbf` is still in the future. 1103 means the token is no longer valid because `exp` has passed. **Should I automatically retry BACH authentication errors?** No. The current Error Codes guidance says authentication failures should not be automatically retried as-is. Correct or regenerate the authentication material first. **Is a 401 authentication failure the same as `TASK_FAILED`?** No. Codes 1100–1103 indicate that the request did not authenticate correctly. `TASK_FAILED` belongs to a later asynchronous generation-task lifecycle. **Is a 403 `Access denied` response the same as 1100–1103?** No. The reviewed Error Codes document that as a different access/geo class rather than the HTTP 401 token-validation group covered here. **See the BACH API General Guide** If you already have an authorized BACH AccessKey and SecretKey, the current documented authentication flow is: ```text AccessKey + SecretKey ↓ Mint HS256 JWT on your server ↓ API_TOKEN ↓ Authorization: Bearer ↓ BACH API ``` Keep the SecretKey server-side. Treat the current `nbf` five-second offset and ten-day `exp` as example values, not universal BACH policy. When authentication returns HTTP 401, use the BACH business code to identify the failed layer: ```text 1101 → header 1100 → token validation 1102 → not yet valid 1103 → expired ``` Official sources: * [BACH API General Guide](https://www.bach.art/docs/v1/general) * [BACH Error Codes](https://www.bach.art/docs/v1/error) * [BACH File Uploads](https://www.bach.art/docs/v1/batch_uploads) * [BACH Callbacks](https://www.bach.art/docs/v1/callbacks)

How to Authenticate BACH API Requests With AccessKey, SecretKey, and JWT

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?