Skip to main content
JSON will be deprecated on November 20th, 2026.
Each example below is one item of a list in your payload file, shown under the name of its list so you can paste it in place. For the full field lists, see create-digital-human, add-agent, update-simulation, and create-custom-metric.

​
Renamed fields

A few fields have a different name in the payload than in the API: When you push a Digital Human, you can also set its voice in one field, in the form language_accent_gender, for example accent: en_american_masculine. Bluejay splits it into language, accent, and gender, and a pull always returns those three fields.

​
Digital Human types

The tag field sets the type of a Digital Human, except for a Customer Journey, which uses journey_steps instead. To keep the examples short, they leave out simulations.
To write the greeting yourself, set tag to voicemail-custom and put the greeting in message, as in the example. To have Bluejay generate the greeting, set tag to voicemail-ai-generated, set speaks_first_config.mode to ai_generated, and leave out message. A voicemail Digital Human needs no description or success_criteria.
If tag has more than one label, put the voicemail label first, because Bluejay checks only the first label.
To replay a real call, use formatted_transcript in place of description and success_criteria. If you have the call only as raw text, put it in original_transcript instead, and Bluejay uses an LLM to split it into turns.
Each step becomes one call, and Bluejay makes the calls in step order. To learn how journeys work, see Customer Journeys.
Scenario Builder generates Digital Humans with the Scenario tag, workflow_v2_id, workflow_path_index, and enriched_playback. Do not write enriched_playback by hand, because it does not stay in sync with the scenario graph.
Red Teaming generates Digital Humans with attack_vector, attack_type, and attack_plan. Start these from a Red Teaming run, not from Bluejay as Code.

​
Agents

​
Simulations

Push cannot move an existing simulation to a different agent.

​
Custom metrics

metric_type decides which other fields the metric uses. For the metric types and the rules for conditional and composite metrics, see custom metrics.

​
Conditional metrics

This metric checks the copay only on conversations that reach one node of the agent workflow:
fire_conditions holds a list of groups, and each group holds a list of conditions. The join inside a group says how its conditions combine, and the join on fire_conditions says how the groups combine. Set join to and (the default) or or. A metric can have 10 conditions at most. Each condition has a type, and each type needs its own fields: Supported values for operator include:
  • equals
  • not_equals
  • greater_than
  • less_than
  • greater_than_or_equal
  • less_than_or_equal
  • contains
  • not_contains

​
Composite metrics

To give a number, combine the input metrics in master_formula:
To give a label instead, set output_type to categorical and response_type to enum, and write rules in place of master_formula:
  • List the input metrics in variables. For a metric whose result is not a number, such as Pass/Fail, add a value_map that turns each result into a number, for example pass: 5 and fail: 1.
  • In master_formula, refer to a metric by its ID in double quotes. Supported operators include:
    • +
    • -
    • *
    • /
    • %
    • **
  • Supported functions include:
    • min
    • max
    • abs
    • round
    • floor
    • ceil
  • Bluejay checks rules in order and uses the first match. If no rule matches, the result is Not Applicable.
  • A composite metric can have 10 rules at most, each with 10 conditions at most. A rule can read only the metrics listed in variables, and its conditions use the same operators as conditional metrics.
Last modified on October 21, 2026