Adding a Second CometAPI Key in Dify Does Not Create a Second Model

General
1

When replacing a CometAPI key in Dify, do not assume Add Model means “make another model.” Dify’s model-provider documentation says that a custom model matching an existing model’s name and type receives the new key instead of becoming a duplicate entry. It also says custom models manage their own keys, and deleting the only key removes the model.

That distinction matters for the CometAPI integration. CometAPI’s Dify guide documents the generic OpenAI-compatible provider, the base URL https://api.cometapi.com/v1, a CometAPI key, and custom model entries for IDs that are not already listed. In that setup, first identify the existing model’s name-and-type identity. Attach the replacement credential there, confirm that the model is still selectable in the target node, and make a representative request if your change procedure permits it. Only then remove the superseded credential.

This is a safe sequencing recommendation, not a claim that Dify rotates or revokes CometAPI keys automatically. It also does not prove zero downtime: verify the actual Cloud provider screen and your node before retiring the old key. The practical rule is to preserve the model mapping while changing its credential, rather than creating a second mapping by accident or deleting the model’s only key.

Sources: Dify Docs, “Model Providers” (Model Providers - Dify Docs); CometAPI, “How to Add OpenAI, Claude, Gemini, and DeepSeek to Dify” (How to Add OpenAI, Claude, Gemini, and DeepSeek to Dify - CometAPI).

2

A representative request needs a sharper acceptance criterion: did the replacement credential work, or did the model merely remain callable? Those are different observations while the old credential is still available. Dify’s model-provider documentation says a matching custom model name and type receives the additional key; that statement alone does not establish which key a subsequent request used.

For a credential-only change, I would hold the provider, endpoint, exact model name, model type, and test input constant. Record the replacement credential using a non-secret administrative label—not its value—and require evidence that the successful check used that credential. If the provider screen offers an individual credential validation, check what that validation actually covers; do not assume it exercises the target node. A node request and a credential validation answer different questions.

If the available interface cannot distinguish the credentials, mark replacement-key verification as unresolved rather than treating a successful request as permission to retire the old one. This is a proposed acceptance test, not a claim about Dify’s credential-selection behavior. It also keeps a model or endpoint migration out of the rotation test, where it would make a failure harder to attribute.