SDK Updates: v3.1.0

[postman]

SDK updates

Changed

• Model exports in models/__init__.py now use PEP 562 __getattr__ for lazy loading; classes are imported on first access and cached rather than eagerly loaded at module-import time, significantly reducing startup time for SDKs with large model counts
• Generated registries for lazy model loading are now deduplicated to avoid duplicate dict key warnings in consumer codebases

Fixed

• Forward reference resolution in Pydantic models with circular dependencies now works correctly; model_rebuild() is batched across all eligible BaseModels after all models are loaded into the module namespace
• ApiError now properly displays the HTTP status code and message when converted to a string or printed in tracebacks (previously showed only the class path)
• API key snippets no longer override the api_key_header parameter with a placeholder value; the SDK's default header name from the spec is now used
• Snippet code for isAnySchema parameters no longer crashes with NameError: name 'Any' is not defined and now honors spec-provided examples
• Parameters typed Any no longer crash at runtime with TypeError: typing.Any cannot be used with isinstance()
• Imports no longer fail with ImportError: cannot import name 'Any' from <sdk>.models
• Environment URLs with missing hosts (e.g., https:///) no longer raise ValueError at SDK import time
• File-upload snippets no longer crash with FileNotFoundError for missing test fixtures
• Enum member names with leading/trailing underscores (e.g., _FOO_) are now properly sanitized
• Property names that collapse to a single underscore after non-ASCII character removal are now renamed to avoid Pydantic validation errors

Added

• GraphQL schema mapper now translates GraphQL Query and Mutation root fields into ApiContext service methods with kind: 'graphql', mapping field arguments to variablesSchema and return types to both responseDataSchema and GraphQL-aware responseEnvelopeSchema for downstream generators
• Shared GraphQL schema type mapper for translating GraphQL schema types (objects, input objects, enums, scalars) into generator-friendly internal structures (Models, Schemas, EnumModels), with conservative fallback behavior for unsupported constructs (interfaces, unions)
• GraphQL scalar mapping strategy now translates built-in GraphQL scalars (ID, String, Int, Float, Boolean) and the common Upload extension scalar into shared schema types, with custom scalars conservatively mapping to ANY while preserving original names in typeDefinition for downstream specialization
• GraphQL endpoint transport normalization utility now resolves GraphQL base URLs and endpoints into the standard SDK environment model, supporting absolute URLs, relative paths, and default endpoint inference while maintaining compatibility with per-language transport implementations
• API key authentication helper now resolves both parameter name and location from security schemes, enabling language generators to route credentials to headers, query parameters, or cookies as declared in the spec
• Schema-derived GraphQL services are now grouped deterministically by root operation type (Query and Mutation), ensuring stable SDK surfaces across regenerations even when the schema defines custom root type names
• Generated SDKs with GraphQL operations now emit operation-based snippet representations alongside the existing endpoint-based snippets, allowing richer documentation for schemas where multiple operations share the same transport endpoint

Fixed

• GET and HEAD operations no longer carry request bodies, eliminating spurious 415 Unsupported Media Type errors when Postman collections have bodies attached to these methods (the spec-derived SDKs now correctly surface GET/HEAD as bodyless across all languages)
• OpenAPI specs with path-style internal $ref (e.g., #/paths/~1api~1v2~1warehouses/get/responses/202) now resolve correctly instead of throwing invalid reference errors
• The sdkConfig.inferServiceNames: false option now prevents service fragmentation; when disabled, all requests collapse into a single root service named after sdkName, restoring the flat client surface for collections converted from OpenAPI specs
• Generated SDKs now use the correct apikey header name when generated from Postman collections with omitted in field (Postman implicitly defaults to header; SDKs were previously selecting the wrong scheme from the spec)
• Postman-collection-derived SDKs no longer expose Accept and Content-Type as method parameters; both are transport-layer headers managed by the SDK itself, and exposing them (especially Postman's default Accept: application/json) caused 406 NotAcceptable errors against endpoints with different declared response types
• OpenAPI specs that declare Accept or Content-Type as header parameters no longer surface them as method parameters, bringing the generator into compliance with OpenAPI 3.0 §4.7.12.1
• Response content type is now correctly inferred from Postman saved-response examples instead of hard-coded to application/json; JSON examples with unparseable bodies (e.g. placeholder strings) are downgraded to text/plain to match postman2openapi's inference
• Postman collections with leftover Content-Type: application/json headers on multipart and urlencoded requests (common on image uploads and form submissions) now generate SDKs that send the correct content type; the generator now follows body.mode instead of request-level headers for these cases
• Postman collections with author-documented variable values (e.g. instance: 'instance (Instance name)', endpoint: 'https://api.example.com (Domain of your API)') now generate SDKs with correct URLs and method signatures; the postman-mapper strips trailing (description) annotations, drops self-referential placeholder values that would otherwise inline as constant URL segments instead of path parameters, and defensively coerces non-string variable values (numbers, booleans, null)

Security

• SDK name, package name, and version fields are now sanitized at ingestion to prevent template injection attacks; user-controlled identifiers interpolated into generated source code no longer risk enabling EJS escape sequences that could execute arbitrary code on downstream consumers
• Service and model names derived from OpenAPI specs (operation tags → service names, schema titles and $ref paths → model names) are now sanitized at the api-context layer to prevent injection attacks; word-boundary characters (space, dot, hyphen, underscore) are preserved so per-language naming strategies can still split tokens, while escape characters that could break out of generated literals are removed
• Free-text SDK metadata fields (homepage, author name/email) are now sanitized at the config ingestion chokepoint to prevent template injection through generated build manifests; literal break-out characters (quotes, backticks, braces, angle-brackets, backslash) are stripped while ordinary prose (URLs, descriptive sentences, names with punctuation) is preserved