Parameters

Each service exposes a set of named parameters that influence its output. Parameters are typed (string, boolean, enum) and have default values.

Two ways to set parameters

There are two ways to configure a service's parameters for an order:

• Pass them explicitly in parameter_values on each order (covered below). Best when you want to set options flexibly from your side and they vary order to order.
• Save a preset in the platform UI and reference it by preset_id. Best when you have a clear, stable configuration per service and don't want to repeat it in code. You can still override individual parameters per order.

The rest of this page covers the explicit parameter_values route. For presets — including how to combine a preset with per-order overrides — see Presets.

Passing parameters explicitly

Pass them in the parameter_values field when creating an order:

"parameter_values": {
  "base_type": "palate",
  "guide_thickness": 2.3
}

Parameter keys are always snake_case, matching the field names in the service's schema. Omit any parameter to use its default.

Where to find the allowed options

Every service has its own set of parameters with its own allowed values.

Three ways to discover them:

• View API Example. On the service card in the platform UI, open the three-dots menu and click View API Example to copy a ready-to-run snippet with the right parameter keys for that service. Fastest path.
• Runtime. Call GET /services/{id} and read the parameter_schema in the response. Useful if you want to render a parameter UI dynamically.
• API reference. The POST /orders entry lists the shared shape of the request body; service-specific keys still come from the routes above.

Example: models for retainer

The models-for-retainer-v1 service produces orthodontic models ready for retainer printing. Its parameter_values might look like:

"parameter_values": {
  "smoothing_iterations_tooth": 1,
  "smoothing_iterations_mandible": 2,
  "decimate_max_error_tooth": 0.03,
  "decimate_max_error_mandible": 0.1,
  "target_coordinate_system": "ios",
  "extension": ".ply"
}

Every field above comes from that service's parameter schema, not from a shared global list. A different service — say, the bite-plate service — has a completely different parameter set (base_type, base_reinforcement_type, …). Always look up the schema for the service_id you're posting against via View API Example or GET /services/{id}.

Pre-filling parameters in draft orders

For draft orders, any value you include in parameter_values pre-fills the corresponding field in the iframe. The end user can still override it before submitting — the finalize call treats the frontend payload as authoritative. Leave a parameter out to surface it as the service's default.