Skip to main content
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
  2. Trigger the Blueprint 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, each picker card represents a Blueprint. The selected Blueprint determines which primary authentication strategy and credential form Rubie displays.

​
Identifiers you’ll use

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 refKeys and configured metadata items. See Triggering 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.