Conversation
StellarNexus Consulting UG
DE
Last activity: 17 Oct 2025 11:10 EDT
Blueprint OpenAPI import – embedded objects on import
Hello Team,
Could you confirm whether GenAI Blueprint supports importing embedded objects (Page) and embedded lists (PageList) directly from an OpenAPI 3.0.3 specification during import, rather than setting them up manually after import
If the answer is yes, could you please clarify which OpenAPI patterns Blueprint recognizes as embedded?
Minimal example (generic)
openapi: 3.0.3
info: { title: Demo, version: '1.0.0' }
components:
schemas:
Address:
type: object
properties:
street: { type: string }
city: { type: string }
Contact:
type: object
properties:
type: { type: string }
value: { type: string }
# Wrapper that composes Address
AddressWrapper:
allOf:
- $ref: '#/components/schemas/Address'
Person:
type: object
properties:
# Single embedded object candidates
addr_A:
$ref: '#/components/schemas/Address'
addr_B:
allOf: [ { $ref: '#/components/schemas/Address' } ]
addr_C:
oneOf: [ { $ref: '#/components/schemas/Address' } ]
addr_D:
type: object
properties:
street: { type: string }
city: { type: string }
addr_E:
$ref: '#/components/schemas/AddressWrapper'
# Embedded list candidates
contacts_A:
type: array
items:
$ref: '#/components/schemas/Contact'
contacts_B:
type: array
items:
allOf: [ { $ref: '#/components/schemas/Contact' } ]
contacts_C:
type: array
items:
oneOf: [ { $ref: '#/components/schemas/Contact' } ]
Questions
-
Is embedded object import supported at all
-
If supported, which of addr_A, addr_B, addr_C, addr_D, addr_E will import as an embedded object (Page)
-
Which of contacts_A, contacts_B, contacts_C will import as an embedded list (PageList)
-
For properties that use oneOf or allOf with a single $ref, should the property include or omit type: object
-
If the target is a wrapper that uses allOf to a base type, is a property referencing the wrapper treated the same as referencing the base type directly
-
Do the target schemas need to be selected and created in the same import for the embedding to be recognized, or is embedding resolved regardless
Best regards,
Midhun
Pegasystems Inc.
IN
Hello @MidhunKrish,
Thank you for the detailed question and example!
At present, GenAI Blueprint does not support automatic creation of embedded data types (Page or PageList) when importing an OpenAPI specification 3.x. These relationships need to be manually configured after import. While this functionality isn’t currently available, we’re actively evaluating enhancements to support it in future iterations. We appreciate your interest and will share updates, though we’re not in a position to provide a specific timeline at this point.
Regarding your second and third questions:
All the patterns you've listed—addr_A, addr_B, addr_C, addr_D, addr_E for embedded objects, and contacts_A, contacts_B, contacts_C for embedded lists—are valid according to the OpenAPI specification. Blueprint recognizes these patterns and, once support is available, will treat them as embedded data types (Address) or lists of embedded data types (Contact) respectively.
Hello @MidhunKrish,
Thank you for the detailed question and example!
At present, GenAI Blueprint does not support automatic creation of embedded data types (Page or PageList) when importing an OpenAPI specification 3.x. These relationships need to be manually configured after import. While this functionality isn’t currently available, we’re actively evaluating enhancements to support it in future iterations. We appreciate your interest and will share updates, though we’re not in a position to provide a specific timeline at this point.
Regarding your second and third questions:
All the patterns you've listed—addr_A, addr_B, addr_C, addr_D, addr_E for embedded objects, and contacts_A, contacts_B, contacts_C for embedded lists—are valid according to the OpenAPI specification. Blueprint recognizes these patterns and, once support is available, will treat them as embedded data types (Address) or lists of embedded data types (Contact) respectively.
For the fourth and fifth questions:
If you're referring to the syntax used to define schema properties (e.g., whether to include type: object when using oneOf or allOf), we aim to honor definitions that conform to the OpenAPI specification 3.x. This applies equally to wrapper schemas using allOf—they are treated consistently with direct references to the base type.
As for the sixth question, we’d appreciate a bit more clarification.
Hope this helps! Let us know if you have further questions or need clarification on any specific aspect.
Thank you.