> ## Documentation Index
> Fetch the complete documentation index at: https://rubie.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Blueprints

> Workflows you and Rubie configure together, triggered through a thin API.

A Blueprint is an executable workflow configured in Rubie: which system to log
into, what to extract or write, how to map and validate the data. The interesting
logic lives in that configuration — not in the API you call.

## Why the API stays small

Whatever a Blueprint does under the hood, the integration surface is the same:

1. Collect a credential via a [hosted credential session](/guides/hosted-credential-collection)
2. [Trigger the Blueprint](/guides/blueprint-runs) with that credential and any inputs
3. Poll the run until it reaches a terminal state
4. Fetch the completed run's outputs directly or through temporary URLs

Adding a new source system usually means Rubie provisions a new Blueprint (and
strategy id) for your account — your application code keeps calling the same
endpoints.

In the [Embedded Credential Capture widget](/guides/embedded-credential-capture),
each picker card represents a Blueprint. The selected Blueprint determines which
primary authentication strategy and credential form Rubie displays.

## Identifiers you'll use

| What Rubie gives you  | Where it shows up                                         |
| --------------------- | --------------------------------------------------------- |
| `blueprintKey`        | Path segment on `POST /blueprints/{blueprintKey}/trigger` |
| `strat_...`           | `strategy_id` when creating a credential session          |
| `cred_...`            | `credential_id` on the trigger request                    |
| `run_...` / `run_key` | Trigger response; status and results requests             |

Your Rubie contact provides the `blueprintKey` and `strategy_id` for each
integration. Treat both as opaque strings.

## Inputs and metadata

Trigger request bodies are defined by the Blueprint, not by a fixed schema.
Top-level keys (other than reserved fields like `credential_id` and `run_name`)
are matched against the Blueprint's INPUT node `refKey`s and configured metadata
items. See [Triggering Blueprint Runs](/guides/blueprint-runs) for the routing
rules.

## Runs

Each trigger creates a Blueprint run. Runs execute asynchronously (`202` on
trigger) and expose a status projection via
`GET /blueprint-runs/{runId}/status`. Status responses never include run
inputs, outputs, or file contents. Once status is `completed`, retrieve outputs
from `GET /blueprint-runs/{runId}/results`.