Parameter Mapping

Each REST operation carries a parameter mapping: the rules that turn the JSON a model passes into a URL, headers, and a body. OpenAPI import generates these; this page is for reading and adjusting them.

The four locations

Location	Field	Goes into
Path	`path_params`	`{placeholders}` in the path template
Query	`query_params`	The query string
Header	`header_params`	Request headers
Body	`body_config`	The request body

Reading a field from the input

Every mapping names a source with from_field, which takes one of two shapes:

{ "from_field": "user_id" }

{ "from_field": ["user", "profile", "id"] }

A string reads one top-level key. An array walks nested objects, one element per level.

Dot notation is not a path. "from_field": "user.profile.id" looks for a top-level key literally named user.profile.id, and fails when it is not there. Use the array form for nested values.

Validation

Path, query, and header mappings each accept validation constraints, applied before the request is built:

Field	Effect
`required`	Missing value is an error
`param_type`	Value must be that type
`pattern`	String must match the regex
`minimum` / `maximum`	Numeric bounds
`enum_values`	Value must be one of the list

A validation failure fails the tool call rather than sending a malformed request.

Validation checks types; it does not coerce them. A string "10" where param_type is integer fails — it is not converted. There is also no default-value field: an absent optional parameter is simply omitted.

Body strategies

body_config has a strategy and an optional content_type (default application/json). The strategy is a tagged object: Whole input as the body:

{
  "body_config": {
    "strategy": { "type": "full_input" },
    "content_type": "application/json"
  }
}

One field as the body:

{
  "body_config": {
    "strategy": { "type": "from_field", "field": "data" }
  }
}

Rename fields on the way through:

{
  "body_config": {
    "strategy": {
      "type": "mapped",
      "mappings": [
        { "to_field": "full_name", "from_field": "name", "required": true },
        { "to_field": "email_address", "from_field": "email", "required": true }
      ]
    }
  }
}

mapped is what you want when the API’s field names are worse than the ones you want the model to see.

A complete example

POST /repos/{owner}/{repo}/issues:

{
  "path_params": [
    { "name": "owner", "from_field": "repo_owner", "required": true },
    { "name": "repo",  "from_field": "repo_name",  "required": true }
  ],
  "body_config": {
    "strategy": {
      "type": "mapped",
      "mappings": [
        { "to_field": "title",  "from_field": "issue_title", "required": true },
        { "to_field": "body",   "from_field": "issue_body" },
        { "to_field": "labels", "from_field": "issue_labels" }
      ]
    }
  }
}

Authentication is not a header mapping. It belongs on the connector’s auth configuration, so the credential stays encrypted and out of the model’s context — see Authentication.

Getting Started

Platform

Built-in Capabilities

Connectors

Agents

Channels

Workflows

Knowledge & RAG

Parameter Mapping

The four locations

Reading a field from the input

Validation

Body strategies

A complete example

Next

​The four locations

​Reading a field from the input

​Validation

​Body strategies

​A complete example

​Next

The four locations

Reading a field from the input

Validation

Body strategies

A complete example

Next