New integrations should use the Guardrails API. The endpoints documented below remain available for accounts that still rely on the legacy set shape.
guardrails_id. The endpoints on this page use the same paths as the new individual API — the server discriminates between the two surfaces based on the request body shape (for POST) or the UUID type (for GET, PATCH, DELETE).
Create guardrail set
POST /v2/guardrails
Send a payload with name and data (an array of guardrail items) to create a legacy set. If you send guardrail_name at the top level instead, the request is routed to Create Guardrails and creates an individual guardrail.
guardrails_id to a persona via guardrails_id on Create Persona.
List guardrail sets
GET /v2/guardrails?legacy=true
legacy=true is the default, so omitting the parameter returns the legacy set list. Pass legacy=false to get a flat list of individual guardrails instead.
Get guardrail set
GET /v2/guardrails/{guardrails_id}
When the supplied UUID is a legacy set UUID, the response returns the set shape:
Patch guardrail set
PATCH /v2/guardrails/{guardrails_id}
Send a JSON Patch array against the set document. Mirror UUIDs are preserved across field-level edits, moves, and removes; a whole-object replace /data/<i> rotates the underlying individual UUID.
Delete guardrail set
DELETE /v2/guardrails/{guardrails_id}
Deletes the set and all of its mirrored individual items. Personas referencing the set via guardrails_id are scrubbed automatically.
Migrating to individual guardrails
The two surfaces interoperate — every guardrail item inside a legacy set is also addressable as an individual guardrail by its ownuuid. To move off the legacy set shape:
- Stop creating new sets. Use Create Guardrails per guardrail.
- Attach guardrails to personas via
guardrail_ids(explicit list) orguardrail_tags(tag-based, dynamic) on Create Persona instead ofguardrails_id. - Existing sets continue to work — personas can mix
guardrails_id,guardrail_ids, andguardrail_tagsduring the transition.

