Keep Seedream boolean parameters typed when importing CometAPI cURL into n8n

If you copy CometAPI’s Seedream cURL example into an n8n HTTP Request node, check the type of watermark before sending the request. Importing the text is not the same as preserving the documented JSON body.

The n8n HTTP Request documentation makes the import rule explicit: “This option always imports any parameter values as strings.” Its remedy for numbers and booleans is to switch Using Fields Below to Using JSON and paste the JSON object.

That matters for a specific field in CometAPI’s Seedream 5.0 Pro guide: the parameter table declares watermark as a boolean, and the cURL example uses "watermark": false for model seedream-5-0-pro-260628 at POST https://api.cometapi.com/v1/images/generations.

Preserve the body, not just the text

For that documented example, I would make the body conversion an explicit step:

  1. Use a new or disposable HTTP Request node for the import. n8n says importing cURL overwrites existing configuration. Keep real keys out of copied commands and shared artifacts; configure authentication separately through n8n’s credential mechanism.
  2. Check the imported method and URL against the CometAPI example above.
  3. Enable Send Body, choose JSON as the Body Content Type, and set Specify Body to Using JSON rather than Using Fields Below.
  4. Paste the typed body. The following retains the example’s fields and values except for a shortened illustrative prompt:
{
  "model": "seedream-5-0-pro-260628",
  "prompt": "Create a product poster with a glass bottle on a stone pedestal.",
  "size": "2K",
  "output_format": "png",
  "watermark": false
}

This is a body example, not an n8n workflow export or a tested request. Notice that "2K" stays a string: preserving types does not mean turning every value that contains a digit into a number.

A small acceptance check before a live call

Inspect the body locally against the documented CometAPI request:

Field Type to preserve Check
model String "seedream-5-0-pro-260628"
prompt String Your image instruction remains text
size String "2K", as in the example
output_format String "png", as in the example
watermark Boolean false, without quotes

The important mismatch is "watermark": "false": that is a string, not the boolean in CometAPI’s example. If you later populate the body from upstream workflow data, repeat the type check on the resolved body rather than relying on how the editor displays the value. Do not send credentials to an external request-inspection service just to check this.

The first acceptance criterion is matching the documented body types, not receiving an image or a successful HTTP status. This walkthrough does not establish whether CometAPI rejects or coerces a string value, or whether it changes watermark behavior. No request was executed here.

The CometAPI guide is a dated example, not proof of current route availability. Verify the current model documentation and schema before a live call. The narrow integration decision remains useful: when moving this Seedream request from cURL into n8n, explicitly preserve its boolean parameter instead of treating a completed import as validation.

I would keep a body-type failure out of the request retry path. For an interactive workflow, the useful distinction is “the request is not ready to send” versus “a valid request encountered a remote failure.” Retrying an unchanged body does not turn "watermark": "false" into "watermark": false.

For this Seedream example, I would use the following local acceptance cases before connecting the request to a user-facing flow:

  • Boolean false: matches the documented example’s watermark value and type; continue to the remaining request checks.
  • String "false": stop before the HTTP step and correct the body construction.
  • Missing watermark: flag it for an explicit configuration decision rather than silently treating absence as false.

That last case is a proposed workflow policy, not a claim that CometAPI requires the field or has a particular default. Likewise, “stop” here means a local check, not a predicted API rejection.

This makes the handoff clearer: a configuration mismatch needs correction, while a remote failure needs separate diagnosis. It also avoids showing a user “retrying image generation” when the workflow has not yet constructed the intended request. These are proposed acceptance cases, not results from an executed n8n workflow.