If you are building an existing-image outpainting job with CometAPI’s bria/expand-image, pause before copying the quickstart into a client. The German-language CometAPI Bria Expand page, captured on September 15, 2026, leaves two implementation questions unresolved: which route to call and how to supply the image being expanded.
The page describes bria/expand-image as CometAPI’s identifier for expanding an existing image beyond its original boundaries. That makes an image-input contract essential to this particular workflow—not a detail that a text prompt can settle.
Where the page does not line up
| Surface on the captured page | What it presents | What needs confirmation |
|---|---|---|
| Integration step 2 | POST /bria/image/edit/expand-image |
The accepted CometAPI expansion route |
| Quickstart summary and API cards | /bria/text-to-image, with links to generate-image documentation |
Whether those references actually apply to this expansion job |
| Integration request example | A body containing only prompt and num_results |
The required source-image field and complete expansion payload |
The page discusses base64 input and publicly accessible image URLs, but that does not identify the CometAPI JSON field to use. Adding a guessed image field would hide the uncertainty rather than resolve it.
These are documentation observations. They do not establish that the live service is broken, that either route is invalid, or that image input is unsupported. No live API test is reported here.
Keep the gateway job contract separate from Bria v2 context
CometAPI’s integration step 3 says the API returns a task ID, then directs readers to poll GET /bria/{task_id} for processing status and the output image URL once complete.
Elsewhere, the specifications describe Bria v2 as returning synchronous results or asynchronous responses with request_id and status_url, depending on processing mode. That separate description is not enough to assume those exact fields are returned by CometAPI’s expansion route. In particular, the polling-path placeholder is not proof of the JSON property name in the submission response.
Plan for the task-polling flow the CometAPI instructions describe, but leave the response parser and completion logic uncommitted until the gateway contract is confirmed.
A concrete implementation gate
Before treating this quickstart as implementation-ready, ask for an expansion-specific CometAPI reference or confirmation covering:
- Submission: the accepted endpoint, required source-image field, supported representation, and complete required request schema.
- Job tracking: the submission response fields, how the returned identifier maps to the polling route, and the documented processing and terminal states.
- Completion and failure: where the output URL appears, how errors are represented, and what polling cadence and stopping conditions the integration should follow.
A human technical reviewer should check those answers against the intended existing-image job before approving the client contract. This is a proposed readiness gate, not a claim that CometAPI mandates that process.
The practical decision is narrow: use this page to outline the integration, not as the sole contract for implementing it. Resolve the expansion route and missing image schema first; do not silently substitute the text-to-image example or Bria v2 response fields for the CometAPI contract you still need.