Skip to content

Choose the model a role uses in this world

PUT
/api/v1/config/router/roles/{id}
curl --request PUT \
--url http://localhost:11044/api/v1/config/router/roles/example \
--header 'Content-Type: application/json' \
--header 'X-Embabel-Api-Key: <X-Embabel-Api-Key>' \
--data '{ "model": "example" }'

A blank model returns a built-in role to the deployment’s choice. A custom role always needs one.

id
required
string

A role id, as GET /config/router lists it

model: one of the chat models GET /config/router lists, trimmed, which the role then uses in this world. Blank or omitted removes the world’s override so a built-in role falls back to the deployment’s choice; a custom role refuses that with 400, as does an unknown model

Media typeapplication/json

Body of PUT /config/router/roles/{id}: the model a role uses in this world

object
model

The model the role uses in this world; blank for the deployment’s choice

string

Example generated

{
"model": "example"
}

Changed; takes effect on the next request

Media type*/*

The change was applied and the world’s config saved; it takes effect on the next request

object
ok
required

Always true. A client that only branches on the status code can ignore it; one that reads the body does not have to special-case the shape

boolean

Unknown role or model

Media type*/*

The change was refused and nothing was saved. The status code says which kind of refusal: 400 for something unknown or invalid, 409 while a context still uses the role

object
detail
required

Why it was refused, written to be shown. Carries the router’s own sentence, which names the context, role or model at fault

string
ok
required

Always false

boolean