Skip to main content

UpsertModel

POST 
/v1/catalog/models

UpsertModel creates or fully replaces a model record.

The provider must already exist (FAILED_PRECONDITION otherwise), and must be enabled if this model is going to be enabled -- an enabled model under a disabled provider could never become routable, yet would read as available. Writing an explicitly DISABLED model under a disabled provider is allowed: neither appears in any route map, so nothing is misrepresented, and it is how a catalog sync stages a provider's models before an operator turns the provider on.

A successful write propagates to the gateway automatically (no separate publish step): the model appears in the data plane's /v1/models and becomes promptable once the refreshed configuration lands. Poll /v1/models to confirm. The exception is suppress_route_regen, which defers that propagation to the caller's own configurator.TriggerUpdate.

is_enabled is tri-state: omit it and the stored value is left alone, so a model an operator disabled is not silently re-enabled by a later write. A new model defaults to enabled.

On update, a field left empty keeps its stored value. To clear a stored value, name the field in clear_fields; to remove a metadata key, name it in remove_metadata_keys. A request that sets neither writes exactly as before.

Request​

Responses​

Success