BizyAir OpenAPI Settings
BizyAir OpenAPI Settings — the per-request override most BizyAir workflows never actually need
- api_config
Here's the thing most people get backwards about this node: you don't need it to use BizyAir's cloud models. Every BizyTRD_*_API node in this pack already knows where the API lives and how to find your key - it reads it from BizyAirPlus's settings or the BIZYAIR_API_KEY environment variable. The BizyAir OpenAPI Settings node exists for the cases where the default answer is wrong, not for the 90% of cases where it's right.
What it does
It's the simplest node in the pack. Two inputs, one output:
- base_url - defaults to
https://api.bizyair.ai/v1, the official BizyAir OpenAPI endpoint. - api_key - empty by default.
It outputs a single api_config value of type BIZYAIR_OPENAPI_CONFIG, which you wire into the api_config input that every BizyTRD_*_API node carries. That input is how you override, for one request, which server and which key the cloud call uses.
When you actually want it
Two situations. First, you're pointing at a different endpoint - maybe a self-hosted or staged OpenAPI server, or an API-compatible gateway. You set base_url to that host and the node handles the rest. Second, you want a specific request to use a different account or a key with a different billing tier than your default, so you paste that key in.
One genuinely important gotcha, straight from the pack's own code: if you override base_url to a different host but leave api_key empty, the SDK deliberately refuses to send your real saved key to that host. It sees an untrusted destination and clears the key rather than leak it in an Authorization: Bearer header. That's a security feature, not a bug - but it means a workflow shared from someone else's setup can silently 401 until you either point it back at api.bizyair.ai or supply your own key. If your cloud call suddenly fails with an auth error after loading a shared workflow, check whether someone's settings node is redirecting you somewhere you didn't expect.
The rest of the pack
The other piece of the cloud puzzle is that these API nodes are registry-driven: the list of models (Flux Kontext, the Gemini editions, the background remover, all of it) is generated from a config that can be refreshed, so new hosted models can appear in your node list after an update without a manual install. The settings node just sits underneath all of it as the override tap.
Install
Same story as the whole pack:
cd /path/to/ComfyUI/custom_nodes
git clone https://github.com/siliconflow/BizyAirPlus.git
cd BizyAirPlus
python -m pip install -r requirements.txt
Restart ComfyUI afterward. You'll find it under the BizyAirModelServices category.
Honest verdict: wire one of these in only when you hit a reason to. If you're just starting and your cloud calls work, this node is dead weight on the canvas - but when a shared workflow quietly redirects your requests, it's the first place you'll want to look.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| base_url | STRING | https://api.bizyair.ai/v1 | — |
| api_key | STRING | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| api_config | BIZYAIR_OPENAPI_CONFIG | — |