ComfyPilotComfyPilot
文档 / 接口 / List the models Comfy Router can run.

List the models Comfy Router can run.

Comfy Router's model catalog - one page of the canonical model IDs that `POST /v2/models/{provider}/{model}` accepts. An SDK calls this on cold start to discover what is runnable, and the `model_not_f…

接口 list-the-models-comfy-router-can-run 更新于 2026-11-13

查看官方原文

List the models Comfy Router can run.

Comfy Router's model catalog - one page of the canonical model IDs that POST /v2/models/{provider}/{model} accepts. An SDK calls this on cold start to discover what is runnable, and the model_not_found suggestions come from the same catalog, so an ID listed here that then 404s on invocation would be worse than either failure alone. That agreement is structural rather than a promise: an entry's provider and model are the two path segments of the invocation route and reference the same schema components that route's path parameters do, and id is those two segments joined by /.

OpenAPI

````yaml /router-openapi.yaml get /v2/models openapi: 3.0.2 info: title: Comfy Router description: >- Comfy Router's public contract: the model catalog and the model-ID-addressed invocation routes, with the error buckets they return. Projected from the canonical Comfy API contract. version: '1.0' servers:

  • url: https://api.comfy.org security: [] tags:
  • name: Comfy Router description: Comfy Router's canonical, model-ID-addressed routes. paths: /v2/models: get: tags:
  • Comfy Router summary: List the models Comfy Router can run. description: >- Comfy Router's model catalog - one page of the canonical model IDs that POST /v2/models/{provider}/{model} accepts. An SDK calls this on cold start to discover what is runnable, and the model_not_found suggestions come from the same catalog, so an ID listed here that then 404s on invocation would be worse than either failure alone. That agreement is structural rather than a promise: an entry's provider and model are the two path segments of the invocation route and reference the same schema components that route's path parameters do, and id is those two segments joined by /. operationId: listRouterModels parameters:
  • $ref: '#/components/parameters/RouterCatalogCursor'
  • $ref: '#/components/parameters/RouterCatalogLimit'
  • in: header name: If-None-Match required: false description: >- The ETag a caller holds from an earlier 200. When it matches the current page (RFC 9110 weak comparison; * matches any current page) the answer is a bodyless 304 carrying the same ETag, otherwise the full page. schema: type: string responses: '200': description: OK - one page of the model catalog. headers: X-Comfy-Request-Id: $ref: '#/components/headers/RouterRequestIdHeader' ETag: $ref: '#/components/headers/RouterCatalogETagHeader' Cache-Control: $ref: '#/components/headers/RouterCatalogCacheControlHeader' content: application/json: schema: $ref: '#/components/schemas/RouterModelListResponse' '304': description: >- Not Modified - the page is unchanged since the ETag the caller sent in If-None-Match. No body is returned. headers: X-Comfy-Request-Id: $ref: '#/components/headers/RouterRequestIdHeader' ETag: $ref: '#/components/headers/RouterCatalogETagHeader' Cache-Control: $ref: '#/components/headers/RouterCatalogCacheControlHeader' '400': $ref: '#/components/responses/RouterRequestError' '401': $ref: '#/components/responses/RouterRequestError' '403': $ref: '#/components/responses/RouterRequestError' '429': $ref: '#/components/responses/RouterRateLimited' '503': $ref: '#/components/responses/RouterRequestError' security:
  • BearerAuth: []
  • ApiKeyAuth: [] components: parameters: RouterCatalogCursor: name: cursor in: query required: false description: >- Opaque pagination cursor. Pass a previous page's next_cursor to fetch the next page; omit it for the first page. See RouterPageCursor for why the value is opaque and why this route paginates by cursor rather than by offset. schema: $ref: '#/components/schemas/RouterPageCursor' RouterCatalogLimit: name: limit in: query required: false description: >- Number of models to return in one page. Values above the declared maximum are outside the contract, but this route does not reject them: it serves the maximum instead, and the page size actually served is echoed back as limit on the response, so a clamp is always detectable by the caller. Treat the maximum as the real page stride - a client that asks for more and assumes it received more will miss rows. 0 and negative values are also accepted and select the default, which is why no minimum is declared: sub-1 is meaningful here, not invalid. schema: type: integer maximum: 100 default: 20 headers: RouterRequestIdHeader: description: >- Server-generated identifier for this call, present on every Router response - success, 4xx and 5xx alike, because an error response is exactly when a user needs an id to quote in a support request. The same value is written into the call's usage/audit event, which is what lets a complaint about a charge be joined to the charge itself instead of searched for by timestamp. required: true schema: type: string format: uuid example: 6f1a1a6e-6a53-4a5f-9d3a-2b3b0a1f9c21 RouterCatalogETagHeader: description: >- Strong entity tag over the served body's bytes, for GET /v2/models and GET /v2/models/{provider}/{model}. A caller that re-reads the catalog should store this value and send it back as If-None-Match to get a 304 instead of the body. required: true schema: type: string example: '"6b8c1f2e0a9d4c3b5e7f8a1b2c3d4e5f60718293a4b5c6d7e8f90a1b2c3d4e5f"' RouterCatalogCacheControlHeader: description: >- Freshness directives for a catalog page or entry. private because the answer is decided per credential (the response also carries `Vary: Authorization, X-API-Key`), so a shared cache must not hold it, and must-revalidate so a stale copy is revalidated against the ETag rather than served on. Error responses on these routes are `private, no-store` instead. required: false schema: type: string example: private, max-age=300, must-revalidate RouterErrorTypeHeader: description: >- Coarse, machine-readable bucket for the failure, set by Router on every error response. It carries the same value as RouterErrorResponse.error_type, and on the 422 it is the only machine-readable bucket, because that body is the FastAPI detail[] shape and has no error_type field of its own. A client can therefore branch on this header alone, before deciding which of the two Router error bodies it received. required: true schema: $ref: '#/components/schemas/RouterErrorType' RouterRateLimitRetryAfterHeader: description: >- Seconds to wait before sending another request after a 429 carrying error_type: rate_limited: the time until the caller's per-minute request allowance has refilled enough to admit one more request. It is sent on every rate_limited refusal and on no other answer, so it is absent on a 429 whose X-Comfy-Error-Type is concurrency_limit_exceeded or queue_backlog_full. Nothing the caller does drains it early; a request sent sooner is refused again and spends nothing, but gains nothing either. required: false schema: type: integer minimum: 1 example: 2 schemas: RouterModelListResponse: type: object description: One page of the Router model catalog. properties: data: type: array description: The models on this page, at most limit of them. items: $ref: '#/components/schemas/RouterModelListEntry' has_more: type: boolean description: >- Whether another page exists beyond this one. Keep walking while this is true; do not infer the end of the catalog from a short or empty data. next_cursor: $ref: '#/components/schemas/RouterPageCursor' limit: type: integer description: >- The page size actually served. A requested limit above the maximum is clamped down to the maximum rather than rejected, so this can be smaller than the value asked for - paginate with this number, not with the one you sent, or you will assume rows you never received. minimum: 1 maximum: 100 example: 20 required:
  • data
  • has_more
  • limit RouterPageCursor: type: string description: >- An opaque cursor into a Router list. It is produced by the server and only ever round-tripped: it is not an offset, not a model ID, not ordered, and not stable across catalog rebuilds, so parsing one, incrementing one, or persisting one beyond the walk it came from are all outside the contract. Cursor rather than offset because the catalog is a moving list - an offset walk silently skips or repeats entries when entries are added or removed mid-walk, and a caller cannot tell that it happened. pattern: ^[A-Za-z0-9._~+/=-]+$ minLength: 1 maxLength: 512 example: q7Fm2xTn9pLd4RsV RouterModelListEntry: type: object description: >- One entry in the Router model catalog: the identity of a runnable model, and nothing else. The per-model detail route composes this same entry rather than restating it, which is why the name is ...ListEntry and not ...Summary - there must be exactly one definition of what a catalog entry is. Per-model detail and the per-model input/output schemas are their own routes, so this shape stays the minimum a caller needs in order to invoke the model - deliberately, because this is the payload an SDK fetches on cold start. id is provider and model joined by /; the two fields are carried separately as well so a caller composes the invocation path without splitting a string. properties: id: $ref: '#/components/schemas/RouterModelId' provider: $ref: '#/components/schemas/RouterProviderSegment' model: $ref: '#/components/schemas/RouterModelSegment' billing: $ref: '#/components/schemas/RouterModelBilling' schema_etag: type: string description: >- The current strong ETag of this model's `GET /v2/models/{provider}/{model}/openapi.json` document. Send it as If-None-Match on that read to get a 304 while the schema is unchanged, or compare it with the value seen last time to learn which models' schemas changed without fetching every document. Absent whenever that read would not answer 200 for this caller at this moment: the schema service is not available, the model's document cannot be rendered, or the model stopped being available to this caller while the response was being built. An absent tag is not a schema change; re-read the model's document to learn its current tag. example: '"9f2c1e0b7a4d3c6e8f5a2b1d0c9e8f7a6b5c4d3e2f1a0b9c8d7e6f5a4b3c2d1e"' required:
  • id
  • provider
  • model
  • billing RouterErrorResponse: type: object description: >- Router's request-level error body: what is returned when the request never reached the model, or failed for a reason the model itself did not report - auth, quota, an unknown model ID, or provider transport. A model-level validation failure has its own shape, RouterValidationErrorResponse, because flattening a FastAPI detail[] array into this detail string would destroy the per-field granularity an SDK branches on. properties: detail: type: string description: >- Human-readable description of the failure, safe to surface to an end user. Not machine-parsed - branch on error_type instead. For model_not_found on a retired model, detail reads `<id> was retired on <YYYY-MM-DD>; use <successor>` when a successor is recorded and visible to the caller, or just `<id> was retired on <YYYY-MM-DD>` when it is not, instead of the usual suggestion list. A successor named here is always a live catalog ID the call can be re-pointed at. A model whose sunset date is still in the future is not retired: it stays listed by GET /v2/models and stays runnable until that date. Like the rest of detail, this retirement wording is for display and carries no compatibility guarantee. error_type: $ref: '#/components/schemas/RouterErrorType' upstream_detail: type: string description: >- A bounded, sanitized reason for an invalid_input rejection. On the synchronous route it is the reason the model provider gave, present only when error_type is invalid_input and X-Comfy-Upstream-Status is a provider 4xx or 2xx - i.e. the provider refused the request as malformed and said why. Usually that status is a 4xx; it is a 2xx for a provider that reports a rejected generation inside a success envelope (a BytePlus failed-task poll is HTTP 200 with the reason in its body). There it is absent on every other failure, including provider 5xx, transport failures, content-policy refusals and any refusal Router raised about itself, and it mirrors the X-Comfy-Upstream-Detail header. The queued collect (`GET /v2/models/{provider}/{model}/requests/{request_id}`) of a run that ended invalid_input carries the same reason in this field on its first collect, which then deletes it from the request: a later collect normally answers the same error_type and detail without it, so read it from the first collect. That read sends neither header. The queued collect also uses this field for Router's own reason when Router refused the request before sending it to the provider and can state why in one sentence, which the synchronous route answers in detail; a refusal that names individual fields carries none. refusal_subject: type: string description: >- Which input or output a content-policy refusal was about, as a Router-level closed vocabulary: input, output, input_text, input_image, input_video, input_audio, output_text, output_image, output_video, output_audio. The bare input / output values name the side when the provider did not name a modality. Present only when error_type is content_policy_violation and the provider named the refused subject with a machine-readable code; absent otherwise. Never provider text. Named today for BytePlus, Runway, BFL, Gemini, Veo, Vertex, xAI and Wan refusals, and for the MiniMax Router's Nano Banana legs' Gemini refusals; a provider whose refusal does not say which side it was about leaves it absent. It mirrors the X-Comfy-Refusal-Subject header. denied_reason: type: string description: >- Billing's policy branch for a partner-node spend denial - no_funds when the billed wallet is empty, unspecified when the call was refused without a funds reading saying so. Present only when error_type is insufficient_credits and the deployment reports wallet facts; absent otherwise. A machine-readable code, not display text: show detail, branch on this. billed_workspace: $ref: '#/components/schemas/RouterBilledWorkspace' credential_kind: type: string description: >- How the refused request authenticated - personal_api_key, team_api_key, personal_session or team_session. Answers "which credential do I switch to bill the other wallet?". It is not a permission and grants nothing. Present only alongside denied_reason. required:
  • detail
  • error_type RouterModelId: type: string description: >- A canonical Comfy Router model ID, {provider}/{model} - exactly the value that addresses the model on POST /v2/models/{provider}/{model}, so a caller can interpolate it into that path without re-deriving it from anything. Its pattern is RouterProviderSegment and RouterModelSegment joined by a single /, and maxLength is their sum plus that separator. pattern: ^[a-z0-9]+([._-][a-z0-9]+)/[a-z0-9]+([._-][a-z0-9]+)$ maxLength: 193 example: bfl/flux-2-pro RouterProviderSegment: type: string description: >- Lowercase provider segment of the canonical {provider}/{model} model ID - the partner whose model is being addressed. The invocation route's provider path parameter and a catalog entry's provider field both reference this one schema, which is what keeps the listed IDs and the accepted IDs from drifting apart. pattern: ^[a-z0-9]+([._-][a-z0-9]+)*$ maxLength: 64 example: bfl RouterModelSegment: type: string description: >- Lowercase model segment of the canonical {provider}/{model} model ID
  • the model to run within that provider. Shared by the invocation route's model path parameter and a catalog entry's model field, for the same no-drift reason as RouterProviderSegment. pattern: ^[a-z0-9]+([._-][a-z0-9]+)*$ maxLength: 128 example: flux-2-pro RouterModelBilling: type: object description: >- Per-model billing facts a caller needs before invoking - not prices. Usage and cost figures never appear here. properties: charges_on_policy_rejection: $ref: '#/components/schemas/RouterChargesOnPolicyRejection' required:
  • charges_on_policy_rejection RouterErrorType: type: string description: >- Coarse, machine-readable bucket for a Router failure, mirrored on the X-Comfy-Error-Type response header so a caller can branch without parsing the body. The set is closed at twenty values: the six request-level buckets invalid_input, content_policy_violation, provider_error, provider_timeout, insufficient_credits and model_not_found, plus the transport-level unauthorized, forbidden, concurrency_limit_exceeded, client_disconnected, internal_error, deadline_exceeded, not_enabled, service_unavailable, rate_limited, cancelled, queue_timeout, request_not_found, queue_backlog_full and result_expired. Closed describes the set as documented today, not a bound that holds forever: the set is expected to grow, which is why this is deliberately a plain string and not an enum, so a client must treat an unrecognised value as internal_error rather than switch exhaustively over the list above and break on the next addition. example: invalid_input x-comfy-error-types:
  • value: invalid_input tier: request meaning: >- The request was rejected before it reached the model - a malformed body, a malformed or expired pagination cursor, an input the model's own schema does not accept, or an Idempotency-Key that cannot serve this request (already used for a different request - the method, the path and query, or the body differ - or already consumed by a call whose response cannot be replayed). Sent with 409 in the key cases and with 400/422 in the others; the status says which, and the key cases are the ones answered by using a new key rather than by editing the request.
  • value: content_policy_violation tier: request meaning: >- The provider refused the request on content-policy grounds. The refusal is deterministic: re-sending the same input will be refused again.
  • value: provider_error tier: request meaning: >- The partner provider reported a failure of its own, or returned a response Router could not interpret as a result.
  • value: provider_timeout tier: request meaning: >- The partner provider did not answer within its deadline. This bucket is the provider timing out and never Router's own server deadline, which is reported as deadline_exceeded - the two share 504 and are separated because they name different causes: this one says the partner failed, that one says Comfy stopped holding the connection.
  • value: insufficient_credits tier: request meaning: The calling workspace does not have enough credits to run the model.
  • value: model_not_found tier: request meaning: >- The {provider}/{model} ID names no model Router can run: an unknown provider, an unenrolled id, one the catalog has retired past its sunset date, or a catalogued ID the provider does not currently serve for Comfy. A retired id's detail reads `<id> was retired on <YYYY-MM-DD>; use <successor>` when a successor is recorded and not withheld, or just <id> was retired on <YYYY-MM-DD> when it is not, instead of a suggestion list; the successor named for a retired id is always a live catalog ID you can re-point the call at, and a successor is dropped from detail either because the table records none, or because the recorded one is currently withheld behind an embargo the caller cannot see. A model whose sunset is still in the future is not withdrawn: it stays listed by GET /v2/models and stays runnable until the date, so a listing taken today remains the answer to what runs today. Otherwise detail carries up to three suggestions drawn from the models the caller is entitled to see, except for a catalogued ID the provider does not currently serve for Comfy, whose response carries no suggestions.
  • value: unauthorized tier: transport meaning: The request carried no usable credential.
  • value: forbidden tier: transport meaning: >- The credential is valid but is not entitled to this model or this operation.
  • value: concurrency_limit_exceeded tier: transport meaning: >- The workspace already has as many calls in flight as it is allowed; retry once one of them finishes. It carries one further condition on the run route, on a 409 rather than the 429 above: another call is already in flight for the Idempotency-Key this request presented. Re-send the same key after Retry-After seconds to collect that call's result.
  • value: client_disconnected tier: transport meaning: >- The caller closed the connection before Router could return a result. It is logged rather than delivered - there is no socket left to write it to - and it is an attribution, not a billing outcome: a provider generation that completed is billed regardless of whether the caller received the response.
  • value: internal_error tier: transport meaning: >- Router itself failed. It is also the value a client should treat any unrecognized bucket as, so a later addition to the set does not break a client generated before it.
  • value: deadline_exceeded tier: transport meaning: >- Comfy stopped holding the connection at its own configured bound before an answer arrived. It shares 504 with provider_timeout and the pair says which side ran out of time; this one is Comfy's own bound, so nothing about the request was rejected and the same request may be retried. It says nothing about the charge: a provider generation that completed is billed regardless of whether the caller received the response. Retry it with the same Idempotency-Key: when the provider had already accepted the generation, the retry collects that generation rather than dispatching another, and a Retry-After on the 504 says when to ask.
  • value: not_enabled tier: transport meaning: >- Comfy Router is not switched on for this caller yet. Nothing about the request is wrong and the model exists, which is why this is not model_not_found; it shares 403 with forbidden and is not the same thing, because forbidden is an entitlement decision about the caller while this is a state of the rollout. It is terminal: do not retry, and do not treat it as an outage. The one exception to "about the caller" is the queued submit, which also answers not_enabled for a model whose partner answers a generation directly as bytes: that model cannot yet be queued, so it is the model and not the caller that is refused, nothing is queued or charged, and the synchronous route POST /v2/models/{provider}/{model} runs it instead.
  • value: service_unavailable tier: transport meaning: >- A service Comfy Router depends on is temporarily unavailable and the caller did nothing wrong. Retry it with backoff: it is the one bucket here whose condition clears on its own, without the caller changing the request and without a concurrency slot freeing, which is what distinguishes it from the other retryable answers (concurrency_limit_exceeded, deadline_exceeded). It is separate from internal_error - which is a 500 and means Router itself failed - so a client can tell "come back shortly" from "this call is not going to work".
  • value: rate_limited tier: transport meaning: >- The caller has spent an allowance measured over a window and must wait for that window to roll. It shares 429 with concurrency_limit_exceeded and is not the same thing: that one clears the moment one of the caller's own in-flight calls finishes, so retrying in seconds is right, whereas nothing the caller does drains this one early. detail names the window, and Retry-After the seconds to wait.
  • value: cancelled tier: transport meaning: >- A queued request was withdrawn — through the cancel route, or by an operator — before it produced a result; it is terminal, and it is not by itself a statement about the charge. Cancelling stops Comfy waiting and it does not always stop the partner working, so a request cancelled while it was still IN_QUEUE was never dispatched and cannot be charged, whereas one cancelled after it was admitted may still be charged — a partner generation that completes is charged whether or not anyone collected it, which is why the cancel route calls the ask a request rather than a guarantee. It is not client_disconnected: that one says nobody is listening any more while a generation may still be running and billable, whereas this says the request itself was withdrawn. A caller polling the status read sees 200 with this in the body, because the request ended and so the read succeeded. Collecting the result of such a request answers 409 in Router's error envelope: that read also worked, and what it found is a request whose terminal state - the caller's own decision - leaves nothing to return. It is deliberately not 410, which on that route means the result aged out of its retention window, and not a 5xx, which would report the caller's own cancellation as a Router fault and read to a polling client as worth retrying.
  • value: queue_timeout tier: transport meaning: >- A queued request waited past its queue timeout without ever being admitted. Terminal, unbilled, and it never took a concurrency slot — the job never reached a provider. Deliberately not deadline_exceeded, which is the synchronous route's connection bound: a deadline_exceeded generation may be running and billable, whereas this one provably never started. It is returned under 504, which it shares with provider_timeout and deadline_exceeded because a status can only say that a clock ran out; which clock - the partner's, Comfy's connection bound, or the queue's admission bound - is what error_type carries. The request itself is terminal, so submit a new one rather than re-reading this one.
  • value: request_not_found tier: transport meaning: >- The request_id names no request of the caller's under this model. It is the second of the two conditions the queued reads' 404 covers; the first is the {provider}/{model} ID resolving to no partner model, which is model_not_found and carries fuzzy model suggestions. It also covers the right-id / wrong-model URL the path shape refuses, and it is deliberately indistinguishable from a request in another workspace, so a probe with a guessed id learns nothing. A request that has merely aged out of its retention window is 410, not this.
  • value: queue_backlog_full tier: transport meaning: >- The caller already has too many queued requests waiting to run, so this submit was refused. It shares 429 with concurrency_limit_exceeded and is not the same thing: that one is the synchronous route's answer for too many calls in flight at once, whereas the queue accepts a submit at that limit and parks it, and this bucket is the separate bound on how many a caller may leave waiting so that parking cannot mean enqueuing without end. It clears as the caller's own queued requests finish, so retry once some of them complete.
  • value: result_expired tier: transport meaning: >- The request existed and finished, but its result is no longer stored, so the collect has nothing to return. It is returned under 410 and is permanent for that id: re-reading will answer the same way, so do not retry it. It is deliberately not request_not_found, which would tell you the id was never valid and invite re-submitting a generation that has already run. Running the model again means submitting a new request. For a workspace under a zero-data-retention agreement, a queued request's result is not kept after it is delivered: it is removed shortly after the first collect, and an uncollected result is removed after a grace period once the request finishes, so store the result on your side when you first collect it. RouterBilledWorkspace: type: object description: >- The wallet a refused call would have charged, on RouterErrorResponse.billed_workspace. Answers "which wallet is empty?"
  • it is not necessarily the workspace the caller's UI currently has selected, and a team member's personal credential names their personal wallet here even while a funded team is open. Present only alongside denied_reason. properties: id: type: string description: The Cloud workspace id. Absent on the legacy rail. type: type: string description: >- personal or team. An open string: treat any other value as personal. rail: type: string description: >- legacy when the call bills the caller's pre-workspace Metronome customer rather than a Cloud workspace; that customer has no workspace id. Absent for a Cloud workspace. required:
  • type RouterChargesOnPolicyRejection: type: string description: >- Whether a call this model refuses on content-policy grounds is nevertheless charged to the caller. Providers differ, the difference is invisible at call time, and a user who sees an error and a charge for the same call has no way to have known - so it is stated per model, before the call, rather than left to per-provider folklore. When it is yes, a content_policy_violation error on the synchronous route can carry X-Comfy-Credits-Used: it does when the provider refused the model's generated output and Comfy recorded usage for that refused generation, and carries that amount. An input-side refusal, a same-key replay (Idempotent-Replayed: true), and a charge too small to show in the header's two decimals do not carry it; a refusal without the header is not reported, not proof it was free. example: unknown responses: RouterRequestError: description: >- A Router request-level failure - the request never reached the model, or failed for a reason the model itself did not report. The body is RouterErrorResponse and the bucket is repeated on X-Comfy-Error-Type. headers: X-Comfy-Error-Type: $ref: '#/components/headers/RouterErrorTypeHeader' X-Comfy-Request-Id: $ref: '#/components/headers/RouterRequestIdHeader' content: application/json: schema: $ref: '#/components/schemas/RouterErrorResponse' RouterRateLimited: description: >- The caller has spent their per-caller request allowance, which refills continuously over a one-minute window, and the request was refused before Router did anything with it. The bucket is always rate_limited: wait the number of seconds in Retry-After before sending the next request. Nothing was charged, and a request sent sooner is refused again. The body is RouterErrorResponse and the bucket is repeated on X-Comfy-Error-Type. headers: X-Comfy-Error-Type: $ref: '#/components/headers/RouterErrorTypeHeader' X-Comfy-Request-Id: $ref: '#/components/headers/RouterRequestIdHeader' Retry-After: $ref: '#/components/headers/RouterRateLimitRetryAfterHeader' content: application/json: schema: $ref: '#/components/schemas/RouterErrorResponse' securitySchemes: BearerAuth: type: http scheme: bearer bearerFormat: JWT description: >- Bearer token authentication. Normally a Firebase or Cloud JWT. A 'comfyui-' prefixed API key is also accepted in this header: the prefix classifies the value as an API key and it is validated exactly as if it had been sent in X-API-Key. ApiKeyAuth: type: apiKey in: header name: X-API-Key description: >- API key authentication. Send the key in the X-API-Key header; keys are prefixed with 'comfyui-' and are generated from user account settings. The same 'comfyui-' key is also accepted in Authorization: Bearer (see BearerAuth), and when both headers carry a key, X-API-Key wins.

````