# Create an API key Source: https://docs.useblueprints.ai/api-reference/api-keys/create-an-api-key /openapi.yaml post /api/api-keys Creates a new scoped key for trusted integrations and MCP clients. This endpoint accepts only the in-product browser session cookie — `bp_` API keys cannot create other API keys. Use the in-app UI rather than calling this endpoint directly. The plaintext `bp_` key is returned once; store it immediately. # List API keys Source: https://docs.useblueprints.ai/api-reference/api-keys/list-api-keys /openapi.yaml get /api/api-keys Lists keys created by the authenticated account. API keys need the `api_keys:read` scope. # Revoke an API key Source: https://docs.useblueprints.ai/api-reference/api-keys/revoke-an-api-key /openapi.yaml delete /api/api-keys/{id} Revokes a key owned by the authenticated account. API keys need the `api_keys:write` scope. # API authentication Source: https://docs.useblueprints.ai/api-reference/authentication How to authenticate API and MCP requests. External integrations and MCP clients authenticate to the Blueprints API with a `bp_` API key: ```http theme={null} Authorization: Bearer bp_YOUR_API_KEY ``` The web app uses a session cookie set by the in-product login flow. That cookie is browser-only — every programmatic caller (scripts, backends, MCP clients, scheduled jobs) must use an API key. ## API keys API keys are scoped. A key can be broad enough to run a full MCP workflow, or narrow enough to only read blueprints or portfolio data. Treat a `bp_` key like a production credential: keep it server-side or inside trusted local MCP client configuration. Do not ship it in browser code, mobile apps, public repos, synced dotfiles, or frontend bundles. Use API keys for: * Remote MCP clients * Backend services that read or update blueprints * Internal tools that monitor orders, portfolio state, or risk rules * Scheduled jobs that need account-scoped access API keys are not shown again after creation. Store the key in your secret manager or local MCP client config immediately. ## API key scopes | Scope | Allows | | ------------------- | --------------------------------------------------- | | `blueprints:read` | List and read account blueprints | | `blueprints:write` | Create and edit draft blueprints | | `blueprints:deploy` | Deploy, stop, and manually push blueprint nodes | | `orders:read` | Read order activity | | `orders:write` | Approve order intents | | `portfolio:read` | Read balances, positions, portfolio orders, and PnL | | `portfolio:write` | Close positions | | `risk:read` | Read account risk rules | | `risk:write` | Update account risk rules | | `api_keys:read` | List API key metadata | | `api_keys:write` | Revoke API keys | Use explicit scopes for integrations. API keys cannot create other API keys, even when they have key-management scopes. Key creation requires an interactive web session in the Blueprints app. ## Managing keys Create keys from the Blueprints app at [useblueprints.ai](https://useblueprints.ai). Listing keys requires `api_keys:read`. Revoking keys through the API requires `api_keys:write`, but API keys are never accepted by the create-key endpoint. When rotating a key: 1. Create a replacement key in the app. 2. Update the integration or MCP client configuration. 3. Confirm the new key works. 4. Revoke the old key. ## Common auth failures | Status | Meaning | Fix | | ------ | ------------------------------------------------------------ | --------------------------------------------------------------------- | | `401` | The bearer token is missing, expired, malformed, or revoked. | Check the `Authorization` header and rotate the credential if needed. | | `403` | The credential is valid but cannot perform this action. | Add the required scope or use a different key. | | `404` | The resource does not exist for this account. | Confirm the UUID belongs to the authenticated account. | # Create a blueprint Source: https://docs.useblueprints.ai/api-reference/blueprints/create-a-blueprint /openapi.yaml post /api/blueprints Creates a draft blueprint. API keys need the `blueprints:write` scope. You can create an empty blueprint with just a name, or provide an initial visual definition. # Deploy a blueprint Source: https://docs.useblueprints.ai/api-reference/blueprints/deploy-a-blueprint /openapi.yaml post /api/blueprints/{id}/deploy Starts a reviewed blueprint. API keys need the `blueprints:deploy` scope. The response includes the updated status and deployment identifier when deployment succeeds. # Get a blueprint Source: https://docs.useblueprints.ai/api-reference/blueprints/get-a-blueprint /openapi.yaml get /api/blueprints/{id} Returns one blueprint owned by the authenticated account, including its visual definition, deployment status, and current node state when available. API keys need the `blueprints:read` scope. # List blueprints Source: https://docs.useblueprints.ai/api-reference/blueprints/list-blueprints /openapi.yaml get /api/blueprints Returns the authenticated account's blueprints, including status and timestamps. API keys need the `blueprints:read` scope. # Stop a blueprint Source: https://docs.useblueprints.ai/api-reference/blueprints/stop-a-blueprint /openapi.yaml post /api/blueprints/{id}/stop Stops a running blueprint or returns the existing blueprint state if it is already stopped. API keys need the `blueprints:deploy` scope. # Update a blueprint Source: https://docs.useblueprints.ai/api-reference/blueprints/update-a-blueprint /openapi.yaml put /api/blueprints/{id} Updates blueprint metadata or draft visual state. API keys need the `blueprints:write` scope. Active blueprints can reject edits; stop the blueprint first if the product requires a safer edit flow. # Health check Source: https://docs.useblueprints.ai/api-reference/health/health-check /openapi.yaml get /health Returns a lightweight liveness response. Use this for uptime checks that only need to know the API process is responding. # Fetch crypto market data Source: https://docs.useblueprints.ai/api-reference/market-data/fetch-crypto-market-data /openapi.yaml get /api/crypto Fetch supported crypto symbols, recent trade/price series, or kline data for strategy inputs. API keys need the `market_data:read` scope. # Search or fetch Kalshi data Source: https://docs.useblueprints.ai/api-reference/market-data/search-or-fetch-kalshi-data /openapi.yaml get /api/kalshi Search supported Kalshi inputs by query or ticker. API keys need the `market_data:read` scope. # Search or fetch Polymarket data Source: https://docs.useblueprints.ai/api-reference/market-data/search-or-fetch-polymarket-data /openapi.yaml get /api/polymarket Search supported market inputs by text, slug, token, or trending volume. API keys need the `market_data:read` scope. # Approve an order Source: https://docs.useblueprints.ai/api-reference/orders/approve-an-order /openapi.yaml post /api/orders/{id}/approve Approves a pending order intent owned by the authenticated account. API keys need the `orders:write` scope. # List orders Source: https://docs.useblueprints.ai/api-reference/orders/list-orders /openapi.yaml get /api/orders Returns account order activity for review and monitoring. API keys need the `orders:read` scope. Results are scoped to the authenticated account. # API overview Source: https://docs.useblueprints.ai/api-reference/overview Public API basics for Blueprints integrations. The Blueprints API lets authenticated clients work with account-owned resources such as blueprints, orders, portfolio views, risk settings, and connected integrations. ## Base URL ```text theme={null} https://api.useblueprints.ai ``` Use HTTPS for every request. Send and receive JSON unless an endpoint explicitly documents another response type. ## When to use the API Use the API when you are building a service, backend job, internal tool, or approved integration that needs deterministic access to Blueprints data. Use MCP instead when an AI client should help a person inspect or edit blueprints conversationally. MCP exposes tool schemas for AI clients; the API exposes HTTP endpoints for software integrations. ## Endpoint categories * **System status**: liveness checks for basic uptime monitoring. * **Market data**: read-only helpers for market search and supported input discovery. * **Blueprints**: create draft blueprints, read their state, update metadata or visual definitions, deploy reviewed blueprints, and stop running blueprints. * **Trading and account**: read orders, portfolio summaries, and account-level risk rules. * **API keys**: create scoped keys from a web session, then list or revoke key metadata. ## Request basics Authenticated requests use bearer tokens: ```bash theme={null} curl https://api.useblueprints.ai/api/blueprints \ -H "Authorization: Bearer bp_YOUR_API_KEY" ``` Mutation endpoints accept JSON request bodies: ```bash theme={null} curl https://api.useblueprints.ai/api/blueprints \ -X POST \ -H "Authorization: Bearer bp_YOUR_API_KEY" \ -H "Content-Type: application/json" \ -d '{"name":"Election market watcher"}' ``` IDs are UUIDs. Account-owned resources are scoped to the authenticated account, so a valid ID from another account returns `404`. API keys can be scoped to specific capabilities such as `blueprints:read`, `blueprints:write`, `blueprints:deploy`, `portfolio:read`, `risk:write`, or `api_keys:write`. A request with a valid key but missing scope returns `403`. API keys cannot create other API keys. The API playground sends requests directly from your browser to the API. Paste your `Authorization: Bearer bp_...` header in the playground authentication control before sending authenticated requests. If you operate a custom docs domain, include that origin in the API CORS allowlist before relying on playground requests. ## Current scope The API is intended for product clients and approved integrations. It is not a full public SDK yet, so treat endpoint shapes as versioned by the running product. Public unauthenticated routes include health checks, careers form submissions, and BetterAuth infrastructure under `/api/auth/*` (for example sign-in, callbacks, JWKS, and session endpoints). Market-data helpers, account data, and mutations require authentication. ## Response model Successful responses return JSON objects or arrays. Error responses include an HTTP status code and a message suitable for display or logging. Common statuses: * `400`: request validation failed * `401`: authentication is missing or invalid * `403`: the credential is valid but cannot perform the action * `404`: the requested resource was not found or does not belong to the caller * `429`: too many requests * `500`: unexpected server error * `503`: temporary service or upstream dependency issue # Close a position Source: https://docs.useblueprints.ai/api-reference/portfolio/close-a-position /openapi.yaml post /api/portfolio/positions/close Creates a sell order intent to close part of an account position. API keys need the `portfolio:write` scope. Review the current position before calling this endpoint. # Get portfolio overview Source: https://docs.useblueprints.ai/api-reference/portfolio/get-portfolio-overview /openapi.yaml get /api/portfolio Returns account-level portfolio summary data such as running blueprints, open positions, pending orders, and aggregate PnL. API keys need the `portfolio:read` scope. # Get risk rules Source: https://docs.useblueprints.ai/api-reference/risk-rules/get-risk-rules /openapi.yaml get /api/risk-rules Returns account-level trading safeguards used before live trading actions are allowed. API keys need the `risk:read` scope. # Update risk rules Source: https://docs.useblueprints.ai/api-reference/risk-rules/update-risk-rules /openapi.yaml put /api/risk-rules Updates account-level safeguards such as order size, daily loss, open position, order-rate, cooldown, and approval thresholds. API keys need the `risk:write` scope. # Health check Source: https://docs.useblueprints.ai/api-reference/system/health-check /openapi.yaml GET /health Check whether the API process is responding. Use this endpoint for lightweight uptime checks. It does not require authentication and does not prove that every upstream dependency is ready. ```bash theme={null} curl https://api.useblueprints.ai/health ``` # Approve an order Source: https://docs.useblueprints.ai/api-reference/trading/approve-an-order /openapi.yaml POST /api/orders/{id}/approve Approve a pending order intent. Approve a pending order intent owned by the authenticated account. API keys need `orders:write`. Use this only after the operator has reviewed the order details and risk rules. ```bash theme={null} curl https://api.useblueprints.ai/api/orders/00000000-0000-0000-0000-000000000000/approve \ -X POST \ -H "Authorization: Bearer bp_YOUR_API_KEY" ``` # Close a position Source: https://docs.useblueprints.ai/api-reference/trading/close-a-position /openapi.yaml POST /api/portfolio/positions/close Queue a close-position order intent. Close part of an account position by creating a sell order intent. API keys need `portfolio:write`. Read portfolio positions first, then submit the exact `tokenId` and `amount` to close. The amount must be positive and cannot exceed the current position size. ```bash theme={null} curl https://api.useblueprints.ai/api/portfolio/positions/close \ -X POST \ -H "Authorization: Bearer bp_YOUR_API_KEY" \ -H "Content-Type: application/json" \ -d '{"tokenId":"1234567890","amount":10}' ``` # Get portfolio overview Source: https://docs.useblueprints.ai/api-reference/trading/get-portfolio-overview /openapi.yaml GET /api/portfolio Read account-level portfolio summary data. Use this endpoint to show an account summary across running blueprints, open positions, pending orders, and aggregate PnL. ```bash theme={null} curl https://api.useblueprints.ai/api/portfolio \ -H "Authorization: Bearer bp_YOUR_API_KEY" ``` # Get risk rules Source: https://docs.useblueprints.ai/api-reference/trading/get-risk-rules /openapi.yaml GET /api/risk-rules Read account-level trading safeguards. Risk rules define the account-level constraints checked before live trading actions. API keys need `risk:read`. ```bash theme={null} curl https://api.useblueprints.ai/api/risk-rules \ -H "Authorization: Bearer bp_YOUR_API_KEY" ``` # List orders Source: https://docs.useblueprints.ai/api-reference/trading/list-orders /openapi.yaml GET /api/orders Read account order activity. Use this endpoint for monitoring and reconciliation views. Orders are scoped to the authenticated account. ```bash theme={null} curl https://api.useblueprints.ai/api/orders \ -H "Authorization: Bearer bp_YOUR_API_KEY" ``` # Update risk rules Source: https://docs.useblueprints.ai/api-reference/trading/update-risk-rules /openapi.yaml PUT /api/risk-rules Update account-level trading safeguards. Use this endpoint to change account-wide safeguards such as max order size, daily loss, open positions, order rate, cooldowns, and approval thresholds. Review changes carefully before saving. These settings affect live trading controls for the authenticated account. API keys need `risk:write`. ```bash theme={null} curl https://api.useblueprints.ai/api/risk-rules \ -X PUT \ -H "Authorization: Bearer bp_YOUR_API_KEY" \ -H "Content-Type: application/json" \ -d '{"maxOrderSize":100,"maxDailyLoss":250,"maxOpenPositions":5}' ``` # What is Blueprints Source: https://docs.useblueprints.ai/getting-started/what-is-blueprints Visual trading automation for prediction markets. Blueprints lets you automate prediction-market trading strategies from a visual workspace across Polymarket and Kalshi. ## Core idea A **blueprint** is a strategy configuration that: 1. Captures the market signal you care about 2. Applies conditions and risk limits 3. Takes action only after reviewable safeguards pass ## Product boundaries * **Authoring:** create and review strategy drafts * **Deployment:** run approved strategies from the app * **Monitoring:** track status, balances, positions, and outcomes ## Who this is for * Individual or team operators running strategy automations on Polymarket and Kalshi * Operators who want a reviewable workflow before putting a strategy live For venue-specific market setup, see [Market node venues and sides](/product/market-node-venues). ## Key terms * **Thesis:** the strategy thesis that informs one or more blueprints * **Blueprint:** configured strategy * **Deployment:** live version of a reviewed blueprint * **Risk controls:** limits and safeguards applied before trading actions # Blueprints Documentation Source: https://docs.useblueprints.ai/index Product docs for Blueprints. ## Blueprints Blueprints is a visual trading automation platform for prediction markets, with support for Polymarket and Kalshi. You define strategy intent, configure automation, then monitor live results from the app. For venue setup details, see [Market node venues and sides](/product/market-node-venues). ## What to read first Product purpose, users, and key concepts. Strategy authoring and review workflow. Live controls, status, and operating expectations. # Connect an MCP client Source: https://docs.useblueprints.ai/mcp/connect Configuration examples for connecting AI clients to Blueprints MCP. Create a Blueprints API key in the app, store it as a local secret, then add the MCP server to your client. ## Requirements * A Blueprints account with API key access * A `bp_` API key created in the app with the scopes your workflow needs * An MCP client that supports remote HTTP servers and custom headers Keep the API key in an environment variable, client secret store, or uncommitted local config. Do not paste it into prompts, shell history, synced editor settings, or checked-in dotfiles. For read-only MCP use, grant `blueprints:read`. For blueprint authoring, add `blueprints:write`. For deploy and stop tools, add `blueprints:deploy`. MCP clients do not need key-management scopes. ## Claude Code ```bash theme={null} read -s BLUEPRINTS_API_KEY claude mcp add --transport http blueprints https://mcp.useblueprints.ai/mcp --header "Authorization: Bearer $BLUEPRINTS_API_KEY" ``` ## Cursor Use your client's secret-management support where available. If your client requires a plain JSON config, keep the file local and uncommitted. ```json theme={null} { "mcpServers": { "blueprints": { "url": "https://mcp.useblueprints.ai/mcp", "headers": { "Authorization": "Bearer ${BLUEPRINTS_API_KEY}" } } } } ``` ## OpenCode ```json theme={null} { "mcp": { "blueprints": { "type": "remote", "url": "https://mcp.useblueprints.ai/mcp", "enabled": true, "headers": { "Authorization": "Bearer ${BLUEPRINTS_API_KEY}" } } } } ``` ## Verify the connection After connecting, ask your client to list your Blueprints MCP tools or call `list_blueprints`. If the client reports authentication errors, confirm that: * The header starts with `Authorization: Bearer`. * The key starts with `bp_`. * The key has not been revoked. * The key has the required scope for the tool you asked the client to call. * The account that created the key still has access to Blueprints. ## First prompt After the connection works, start with a narrow read-only request: ```text theme={null} List my Blueprints blueprints and summarize their current status. Do not edit or deploy anything. ``` Then move into edits only after the client has identified the target blueprint and described the intended tool calls. # MCP overview Source: https://docs.useblueprints.ai/mcp/overview Use Blueprints from MCP-compatible AI clients. Blueprints provides a remote Model Context Protocol server for AI clients that support HTTP MCP servers. ## Endpoint ```text theme={null} https://mcp.useblueprints.ai/mcp ``` The MCP server uses your scoped Blueprints API key to act on your account. ```http theme={null} Authorization: Bearer bp_YOUR_API_KEY ``` ## When to use MCP Use MCP when the operator is working inside an AI client and wants account-aware assistance. The MCP server gives the client structured tools for reading blueprint state, making edits, validating changes, and controlling deployments. Use the HTTP API instead when you are writing a deterministic integration, service, or backend job. ## What MCP is for Use MCP when you want an AI client to help with blueprint authoring and account-aware workflows: * Discover or create blueprints * Read the current blueprint state * Add, configure, connect, and arrange blueprint building blocks * Search supported market inputs * Deploy or stop a blueprint after review The MCP server does not bypass product safeguards. Actions still run as your authenticated account and are subject to the same validation and permissions as the API. Grant only the scopes your MCP client needs. A full blueprint-building client usually needs `blueprints:read`, `blueprints:write`, and `blueprints:deploy`. Omit `blueprints:deploy` for clients that should inspect and edit drafts but never start or stop live automation. ## Operating expectations MCP tools can mutate account-owned blueprints. Review tool calls in your client before approving edits, deploys, or stops. Good MCP prompts are specific about the target blueprint and desired outcome. For example, ask the client to inspect the current blueprint, describe the planned edits, validate the result, and wait for approval before deployment. # MCP tools Source: https://docs.useblueprints.ai/mcp/tools Available Blueprints MCP tools and when to use them. MCP tools are grouped by workflow. Tool names are stable enough for client configuration and prompting, but clients should still read each tool schema at runtime. ## Read-only and mutating tools Read-only tools inspect state or search supported inputs. Mutating tools create, edit, deploy, or stop resources in the authenticated account. Use MCP only in clients you trust with account access. Ask your MCP client to confirm mutating calls before execution, and do not approve deploy or stop actions unless you initiated them. This is especially important for `build_blueprint`, `deploy_blueprint`, and `stop_blueprint`. ## Blueprint management | Tool | Scope | Mutates | Key arguments | Purpose | | --------------------- | ------------------ | ------- | ---------------------- | ------------------------------------------------------ | | `list_blueprints` | `blueprints:read` | No | none | List blueprints owned by the authenticated account | | `get_blueprint_state` | `blueprints:read` | No | `blueprint_id` | Read nodes, connections, layout, and deployment status | | `create_blueprint` | `blueprints:write` | Yes | `name` | Create an empty blueprint | | `rename_blueprint` | `blueprints:write` | Yes | `blueprint_id`, `name` | Rename an existing blueprint | ## Blueprint editing | Tool | Scope | Mutates | Key arguments | Purpose | | --------------------- | ------------------ | ------- | ------------------------------------------ | ----------------------------------------------------------- | | `describe_node_types` | none | No | optional node type filters | Discover supported building blocks and expected inputs | | `validate_blueprint` | `blueprints:read` | No | `blueprint_id` | Check a blueprint for structural and configuration issues | | `add_node` | `blueprints:write` | Yes | `blueprint_id`, `type`, `config` | Add a building block to a blueprint | | `configure_node` | `blueprints:write` | Yes | `blueprint_id`, `node_id`, `config` | Update a building block configuration | | `connect_nodes` | `blueprints:write` | Yes | `blueprint_id`, source and target node IDs | Connect two existing building blocks | | `delete_node` | `blueprints:write` | Yes | `blueprint_id`, `node_id` | Remove a building block and its connections | | `build_blueprint` | `blueprints:write` | Yes | `blueprint_id`, nodes, edges | Add multiple building blocks and connections in one request | | `auto_layout` | `blueprints:write` | Yes | `blueprint_id` | Arrange a blueprint visually | ## Market search | Tool | Scope | Mutates | Key arguments | Purpose | | -------------------- | ----- | ------- | ---------------------- | ------------------------------ | | `search_markets` | none | No | `query` or market slug | Search Polymarket markets | | `search_stocks` | none | No | `query` | Search supported stock symbols | | `search_forex_pairs` | none | No | `query` | Search supported forex pairs | ## Live controls | Tool | Scope | Mutates | Key arguments | Purpose | | ------------------ | ------------------- | ------- | -------------- | -------------------------- | | `deploy_blueprint` | `blueprints:deploy` | Yes | `blueprint_id` | Start a reviewed blueprint | | `stop_blueprint` | `blueprints:deploy` | Yes | `blueprint_id` | Stop a running blueprint | ## Recommended flow 1. Call `list_blueprints` or `create_blueprint`. 2. Call `get_blueprint_state` before editing an existing blueprint. 3. Call `describe_node_types` when the client needs available building blocks. 4. Use editing tools to make the change. 5. Call `validate_blueprint`. 6. Review the result before calling `deploy_blueprint`. ## Prompting pattern For safer edits, ask the client to separate planning from execution: ```text theme={null} Inspect this blueprint, explain the exact edits you plan to make, then wait for my approval before calling any mutating tools. ``` For deployment: ```text theme={null} Validate the blueprint and summarize any warnings. Do not deploy until I explicitly approve. ``` # Portfolio, funding, and risk Source: https://docs.useblueprints.ai/operations/portfolio-funding-risk Operational guidance for account, balances, and risk boundaries. ## Portfolio truth Portfolio state belongs to the account. Strategy attribution is shown for review, but balances and positions remain account-level concerns. ## Funding + credentials * Blueprints uses a Polymarket deposit wallet for live trading. Find the deposit address in the app's funding panel or zero-balance funding interstitial. * Send **USDC on Polygon only** to the deposit address. Do not send assets on other chains, unsupported tokens, NFTs, or exchange-specific wrapped assets unless the app explicitly supports them. * Deposited USDC is converted/wrapped into Polymarket USD (`pUSD`) for trading. Small delays can happen while the on-chain deposit sync and collateral conversion jobs run. * Card funding opens Privy's funding flow and targets the same deposit wallet address. * If the app still shows a zero balance after funding, wait for the deposit sync window and confirm the transaction used Polygon USDC before retrying or contacting support. * Keep exchange credentials scoped to the minimum access needed. ## Risk controls At minimum, enforce: * Position sizing limits * Exposure limits per market/theme * Execution safeguards before order submission * Clear stop/rollback behavior # Account security Source: https://docs.useblueprints.ai/product/account-security How authenticator apps, passkeys, backup codes, and trusted devices work in Blueprints. Use at least two sign-in methods so you can recover access if one device is unavailable. ## Authenticator app (TOTP) * Add an authenticator app from **Settings → Security**. * Scan the setup QR code with your authenticator app. * Enter a 6-digit code to finish setup. * Keep your authenticator app time in sync; invalid clock drift can cause code failures. ## Passkeys * Passkeys let you sign in with Face ID, Touch ID, Windows Hello, or a hardware security key. * Create more than one passkey (for example: laptop + phone) to avoid single-device lockout. * Removing a passkey only removes that credential from Blueprints; it does not erase the passkey from your device keychain. ## Backup codes * Backup codes are one-time recovery codes generated during authenticator setup. * Store them offline in a secure location (password manager vault or printed copy). * Treat each code like a password: never share it in chat, email, or screenshots. ## Trusted devices * When you complete MFA, Blueprints can trust that device for future sign-ins. * Use trusted devices only on personal hardware you control. * Remove trust by signing out, clearing browser data, or disabling/re-enabling authenticator MFA. ## Recovery expectations * If you lose one factor, use another enrolled factor (for example, a second passkey or backup code). * If you lose all enrolled factors and recovery codes, account recovery may require manual support verification and can be delayed. * Keep at least one extra factor enrolled at all times to minimize lockout risk. # Billing, credits, and usage limits Source: https://docs.useblueprints.ai/product/billing-and-usage-limits How plans, credits, checkout flows, and quota gates behave in Blueprints. Blueprints uses credit-based billing with hard quota gates. If a request would exceed your available credits, the action is blocked and the app shows an upgrade flow. ## Plans and included credits * **Community (Free)**: 2,000 credits/month, up to 10 total blueprints, up to 2 running blueprints * **Pro**: \$20/month, 10,000 credits/month, unlimited total blueprints, up to 25 running blueprints * **Teams**: custom limits and pricing via sales Plan limits are enforced server-side. ## Credit top-ups Pro users can buy one-time top-up packs: * **1k**: 1,000 credits for \$10 * **5k**: 5,000 credits for \$45 (10% lower unit price) * **25k**: 25,000 credits for \$212.50 (15% lower unit price) Top-up credits are additive to your recurring plan credits. ## What the app displays In app settings and header: * A credit indicator shows remaining percentage for your current cycle * The billing card shows recurring plan credits separately from top-up balance * Running blueprint usage is shown against your plan limit * If Pro is set to cancel, the UI changes from **Renews** to **Ends** with the end date ## Quota gate behavior Before credit-consuming operations run, Blueprints reserves estimated usage. After completion, usage is finalized against actual usage. If quota is exhausted: * API returns a quota error * The app shows an "out of credits" banner with upgrade CTA * The operation does not continue until credits are available ## Checkout and portal behavior Upgrade and top-up flows open hosted checkout. Return URLs are validated against allowed app origins before redirect URLs are accepted. After checkout return: * The app refreshes billing state * A one-time success/cancel toast is shown in the same browser tab that started checkout * Temporary checkout query params are removed from the URL # Deploy and monitor Source: https://docs.useblueprints.ai/product/deploy-and-monitor Deployment lifecycle and monitoring. ## Deployment lifecycle 1. Select a validated strategy release 2. Start the deployment from the app 3. Confirm live status and risk settings 4. Monitor activity and outcomes ## Live controls * Start or stop each active deployment * Review pending activity after service interruptions * Surface errors and statuses for operator action ## Monitoring signals * Live state of each blueprint * Order and position status * Error messages and failure reasons # Deploy preflight Source: https://docs.useblueprints.ai/product/deploy-preflight Deploy preflight controls, including what is persisted versus visual-only. Blueprints enforces deploy preflight checks before a blueprint can go live. ## Deploy preflight: persisted vs visual-only The pre-deploy panel includes both enforced checks and preview controls. ### Persisted and enforced today * **Onboarding completion**: deploy action stays disabled until account onboarding status is `completed` * **Blueprint validation errors**: deploy action is disabled while validation fails * **Unprotected terminal output warning acknowledgment**: if applicable, deploy requires explicit acknowledgment These states affect deploy eligibility immediately. ### Visual-only controls (not persisted yet) The following controls are currently local UI state only and are not saved to backend deployment configuration: * Limits: max trade size, daily loss limit, max open positions * Schedule: run duration * AI check-in settings: check cadence, watch-for category, permissions, notify channel They are present to preview intended deploy ergonomics, but they do not yet change runtime behavior. # Market node venues and sides Source: https://docs.useblueprints.ai/product/market-node-venues Configure Market nodes for Polymarket or Kalshi and choose YES/NO exposure. Market nodes support two prediction venues: * `polymarket` (default) * `kalshi` ## Venue selection In node configuration, set the market venue first, then choose the market reference for that venue: * **Polymarket:** token ID-backed markets. * **Kalshi:** Kalshi ticker-backed markets (for example `INXD-26DEC29-T4500`). The selected venue is persisted on the node, so downstream pricing and execution use the correct market source. ## YES/NO side selection Market nodes can track either side of the market: * **YES side:** direct yes price/bid/ask. * **NO side:** inverted probability from YES where needed, while preserving spread semantics for that side. Use side selection when your strategy thesis is explicitly contra to the base market statement. ## Update cadence differences * **Polymarket:** live updates are streamed from WebSocket market data. * **Kalshi:** market updates are REST-polled (no public unauthenticated WS stream in current integration path). Because of that, Kalshi node charts and price changes can appear less granular than Polymarket live charts. # Prediction markets guide Source: https://docs.useblueprints.ai/product/prediction-markets-guide A practical primer for using prediction markets in Blueprints. Prediction markets let traders buy and sell contracts whose value tracks the market's estimate that a future event will happen. ## What a prediction market is A prediction market asks a resolved question, such as whether a candidate wins an election or whether a metric lands above a threshold by a deadline. In a binary market, the main outcomes are usually **YES** and **NO**. Contract prices are quoted like probabilities: * A YES price near `0.62` means the market is roughly pricing a 62% chance of YES. * A NO price near `0.38` means the market is roughly pricing the other side. * Prices move as traders add information, disagree, or rebalance risk. ## What resolves a market Every market has resolution criteria: the source, deadline, and exact condition used to decide the outcome. Read those rules before wiring a strategy to a market. Two markets with similar titles can resolve on different sources, dates, or edge-case rules. ## How Blueprints uses prediction markets Blueprints treats prediction markets as both data sources and execution venues: 1. Use a Market node to stream live Polymarket or Kalshi prices into a blueprint. 2. Choose the venue, market, and YES/NO side that matches the thesis. 3. Add conditions and risk controls before any trading action. 4. Review the blueprint, then deploy the approved version. For venue-specific configuration details, see [Market node venues and sides](/product/market-node-venues). ## Building a first strategy Start with a small, inspectable thesis: 1. Pick one market with clear resolution rules. 2. Decide which price movement or threshold would change your view. 3. Add a Market node for the relevant side. 4. Add a condition that represents the signal you care about. 5. Add risk limits before connecting to an output action. Keep the first version narrow. A simple blueprint is easier to review, monitor, and stop if the market behaves differently than expected. ## Risk basics Prediction-market prices can move quickly around news, liquidity can disappear, and resolution wording matters. Treat automated strategies as live trading systems: * Size orders conservatively. * Prefer explicit stop conditions over open-ended automation. * Monitor deployed blueprints and account balances. * Recheck market rules after major news or platform updates. # Schedule node Source: https://docs.useblueprints.ai/product/schedule-node Run a deployed blueprint at a fixed interval. The Schedule node fires a trigger on a recurring interval while a blueprint is deployed. Use it when a strategy should evaluate predictably instead of reacting to every market tick. For example, pair Schedule with a Market node and a Comparison node to check a condition every minute. ## Supported schedule Schedule currently supports interval mode only. Cron expressions are not supported for deployed runtime execution yet. The interval must be at least 1 second. Existing blueprints with invalid or legacy schedule configuration need to be updated before deploy validation will pass. ## Runtime behavior Each deployed blueprint gets its own schedule subscription. Starting, stopping, or redeploying one blueprint does not share the timer with another deployment. Schedule triggers repeat over time, so terminal nodes like notifications, webhooks, and trades can run more than once. Use a Rate Limiter node upstream when you need to cap repeated terminal actions. # Notification delivery Source: https://docs.useblueprints.ai/product/telegram-notifications How to use email and Telegram notification channels, delivery limits, preferences, and failure handling. Blueprints can send deployment and trading notifications to Telegram after you link your account, or by email to your account address. ## Email notifications Choose **email** on a notification node to send the rendered message to the email address on your Blueprints account. Email notifications do not require a Telegram destination, and the deployment worker skips delivery if the account has no email address. Email notification usage is quota-limited by plan: * Free: 10 email notifications per day * Pro: 100 email notifications per hour If the email notification quota is exhausted, Blueprints skips the queued email delivery instead of sending it. If the email sender or quota service is temporarily unavailable, the delivery is retried by the durable notification queue. ## Connect Telegram 1. Open **Settings** in Blueprints and start Telegram linking. 2. Complete the bot link flow. 3. Once connected, your user profile stores the linked Telegram chat. If Telegram is disconnected, Telegram deliveries are dead-lettered and won't send until reconnection. ## Bot commands The Telegram bot command menu includes: * `/start` — connect or check status * `/help` — show command help * `/status` — check account connection status * `/disconnect` — disconnect the linked chat ## Notification preferences You can enable/disable Telegram notifications per event type: * blueprint deployed * blueprint stopped * blueprint error * order filled * order rejected * risk limit hit * custom/other notifications Preferences are persisted on your user record and applied at delivery time. If an event type is disabled, the queued notification is skipped instead of sent. ## Delivery retries and failure behavior Telegram delivery uses a durable queue with retries. * Temporary failures retry with exponential backoff (base 5s, capped at 5 minutes) * Max attempts are capped (default 5) * Permanent failures (for example blocked bot/chat not found) are immediately dead-lettered When a delivery reaches dead-letter state, Blueprints can send a warning email prompting you to reconnect Telegram. Warning emails are cooldown-limited (default 24h) to avoid spam. # Theses workflow Source: https://docs.useblueprints.ai/product/theses-workflow How trading theses connect to strategy blueprints. A thesis captures market intent and constraints before a strategy is configured. ## Recommended flow 1. Define thesis objective and invalidation conditions 2. Map thesis to measurable signals 3. Configure the blueprint around those signals 4. Attach risk boundaries and execution limits 5. Review and deploy the approved version ## Why this matters Separating thesis intent from configuration improves review quality and reduces accidental drift. # Blueprint Studio Source: https://docs.useblueprints.ai/studio/blueprint-studio How strategy authoring works in Blueprints. Blueprint Studio is the workspace used to build and review strategy logic. ## Editing model * Visual strategy layout * Configurable building blocks for signals, conditions, controls, and actions * Reviewable draft state before deployment ## Common building blocks * **Inputs:** market data, crypto data, social/manual triggers * **Logic:** conditions that decide when a strategy may act * **Controls:** limits that constrain activity * **Outputs:** trading actions ## Operational expectations * Draft edits are reviewable and traceable * Deployment uses the reviewed version of a blueprint * Draft changes do not silently alter a live deployment