API Function path, query, and header parameters¶
When you train an API function from OpenAPI, path, query, and header parameters become function arguments. They are not the same as webhook URL parameters (those fill paramsPayload on an inbound endpoint).
Use this page after Using OpenAPI Specs. Host URL mode still applies (Using OpenAPI Specs).
How OpenAPI parameters become arguments¶
For each operation, the translator turns OAS parameters into Specification Input arguments:
in: path→ a required string (or typed) argument; the URL template uses{{argumentName}}in the pathin: query→ an argument; appended as?key={{argumentName}}in: header→ an argument; sent as a request header
Names are camelCased in the trained function. Inspect the generated JSON. Do not assume the SDK argument order without looking: it follows the Specification Input arguments array.
Example OAS fragment:
openapi: 3.0.0
info:
title: Sections API
version: 1.0.0
paths:
/foo/bar/{Section-Id}:
get:
operationId: getSection
parameters:
- name: page
in: query
required: true
schema: { type: number }
description: A query parameter.
- name: x-header
in: header
required: true
schema: { type: string }
- name: section-id
in: path
required: true
schema: { type: string }
responses:
"200":
description: OK
Generate with a host mode flag (this spec has no servers):
$ npx poly model generate ./sections.yaml --context "myApi" --hostUrlAsArgument
Expect a URL template like:
{{hostUrl}}/foo/bar/{{sectionId}}?page={{page}}
After train and npx poly generate, call poly.myApi.getSection(...) with arguments in the order printed in the Specification Input (typically host, then header/query/path, then body if any).
If generate packed or omitted a parameter, edit the Specification Input before train. See Using OpenAPI Specs.
Postman-trained functions¶
Postman training also produces API functions with URL templates. Treat the trained source.url and arguments list as source of truth.