back to manuals

Blueprint Resources

Blueprint resources represent the collection of related components (bots, datasets, skillsets, integrations, etc.) that are organized within a blueprint, providing a comprehensive view of all assets in a specific configuration.

Understanding the resources contained within a blueprint is essential for managing complex AI configurations. The resource list endpoint provides a comprehensive inventory of all components associated with a blueprint, making it easy to audit, manage, and understand the full scope of a blueprint's contents.

Listing Blueprint Resources

The resource list operation retrieves a complete manifest of all resources associated with a specific blueprint. This includes both basic resources (bots, datasets, skillsets, abilities, secrets, files, portals) and integration resources (all types of integrations like widget, Slack, Discord, email, etc.).

To retrieve all resources in a blueprint, make a GET request with the blueprint ID:

The response provides a structured view of all resources organized by type. Each resource includes its essential properties such as ID, name, description, and any relevant relationship IDs (like datasetId, botId, etc.) that show how resources connect to each other.

Response Structure

The response organizes resources into categories for easy navigation:

  • Basic Resources: bot, dataset, skillset, ability, secret, file, portal
  • Integration Resources: widgetIntegration, slackIntegration, discordIntegration, telegramIntegration, whatsappIntegration, messengerIntegration, twilioIntegration, emailIntegration, triggerIntegration, sitemapIntegration, notionIntegration, extractIntegration, supportIntegration, mcpserverIntegration

Each resource entry includes:

  • id: Unique identifier for the resource
  • name: Display name of the resource
  • description: Detailed description of the resource's purpose
  • Relationship IDs: References to related resources (e.g., a bot might have datasetId and skillsetId)
  • meta: Additional metadata and custom properties

Use Cases

Blueprint Auditing: Review all components to ensure your blueprint contains the expected resources and verify that everything is properly configured.

Pre-Clone Planning: Before cloning a blueprint, examine its resources to understand what will be duplicated and plan for any necessary post-clone configuration.

Dependency Mapping: Identify relationships between resources by examining the relationship IDs, helping you understand how components interact within the blueprint.

Resource Management: Use the resource list as a starting point for bulk operations or selective updates to specific resources within a blueprint.

Documentation: Generate documentation or diagrams showing the structure and composition of your blueprint configurations.

Important: The resource list only includes resources that are specifically associated with the blueprint through their blueprintId field. Resources in your account that are not linked to a blueprint will not appear in this list.

Exporting Blueprint Resources

The export endpoint allows you to download a complete blueprint including all its associated resources in different formats. This is useful for backup, version control, migration between environments, or infrastructure-as-code workflows.

JSON Export (Default)

By default, the export returns a JSON representation of the blueprint with all resources organized by category:

The JSON response includes the blueprint metadata (name, description, visibility, config, meta) along with all resources grouped into categories: basic resources (bot, dataset, skillset, ability, secret, file, portals), object resources (space), and integration resources (all integration types).

Terraform Export

To export the blueprint as Terraform HCL code, set the Accept header to application/terraform+hcl:

The Terraform export generates a complete .tf file with provider configuration and all resources defined as Terraform resources. Cross-resource references (such as a bot referencing a dataset) are automatically resolved into proper Terraform resource references.

The response includes a Content-Disposition header with a suggested filename based on the blueprint alias or ID.

Importing Blueprint Resources

The import endpoint allows you to bulk-create resources into an existing blueprint in a single atomic transaction. This is particularly useful when restoring a blueprint from an export, migrating resources from another environment, or programmatically seeding a blueprint with a predefined set of resources.

When you import resources, the platform ignores any id values provided in the payload and generates new platform-managed identifiers for all resources. Cross-references between imported resources (such as a bot referencing a dataset by ID) are automatically resolved using the new generated IDs, so the internal relationships are preserved without any manual ID mapping on your part.

Resource Payload Format

The request body must include a resource object whose keys are resource category names (e.g. bot, dataset, skillset, widgetIntegration) and whose values are arrays of resource objects. Each resource object must include an id field (used only to resolve cross-references within the payload) plus the fields supported by that resource type.

In the example above, local-dataset-1 and local-bot-1 are temporary local identifiers used only to wire up the relationship between the bot and dataset. The platform replaces them with real IDs upon creation and correctly maps datasetId on the bot to the newly created dataset's real ID.

Supported Resource Categories

The following category keys are accepted: bot, dataset, skillset, ability, secret, file, portal, space, extractIntegration, notionIntegration, sitemapIntegration, supportIntegration, emailIntegration, triggerIntegration, widgetIntegration, slackIntegration, discordIntegration, telegramIntegration, whatsappIntegration, messengerIntegration, instagramIntegration, twilioIntegration, and mcpserverIntegration.

Dependency Resolution and Error Handling

The import operation performs a topological sort to determine the correct creation order for resources that reference each other. If cyclic dependencies are detected (e.g. resource A references resource B which references resource A), the request fails with a 400 Bad Request and a detailed error payload describing the cycle. All resources are created inside a single database transaction, so if any resource fails validation or creation, the entire import is rolled back and no partial state is saved.

Note: The blueprint must already exist and belong to the authenticated user. Attempting to import into a blueprint you do not own will return a 401 Unauthorized response.