Runtime and native routes

Staging also accepts organization API keys on runtime routes that accept a company key. Each URL still selects one company by slug. Routes documented as requiring a Console bearer session retain that requirement.

Runtime routes are the project-scoped APIs exposed for a generated company. Console customers use them to connect an existing company to their own app; approved server-to-server integrations use /demo-jobs when they need to create or control normalized jobs programmatically.

For Console customers, runtime routes are the normal first integration surface: create/select a company in the Fictix Console, then copy its project key and base URL from Connect to your builder or Company API keys. See Start In The Fictix Console.

Runtime routes use:

X-API-Key: <project_api_key>

Create a runtime key on the company's API page or under Company API keys. The full secret is shown at creation or rotation. The staging API page also provides a provider selector and a tested first request. Start with Connect your software.

Runtime info

GET /api/v1/orgs/{slug}/info

Returns generated company metadata and runtime details.

Capabilities

GET /api/v1/orgs/{slug}/capabilities

Returns capability metadata available for the generated company.

Execute capability

POST /api/v1/orgs/{slug}/execute

Executes a named capability against the generated company runtime. Read capabilities need read and execute scopes; write capabilities need write and execute. The body's legacy org_id is the company project ID, not the workspace organization ID or company slug. Check status in the JSON response: an execution error may use HTTP 200.

FCI provides derived financial summaries through this surface and retains preview status. It has no native route and is not selectable in the standard connector picker. Confirm capability availability for your company. See the FCI example.

Browse canonical data

GET /api/v1/orgs/{slug}/data/{entity}

Use this when you intentionally work with the org-scoped runtime instead of the partner demo-job surface.

Export canonical data

GET /api/v1/orgs/{slug}/export/{entity}

CSV ledger bundle

GET /api/v1/orgs/{slug}/export-pack/csv

Returns a zip archive containing canonical CSV ledgers and docs.

Expected bundle behavior:

• one zip file
• all canonical ledgers
• README
• schema metadata
• normalized line files where available
• no duplicate payments.csv and customer_payments.csv
• no duplicate bill_payments.csv and vendor_payments.csv

Provider export packs

GET /api/v1/orgs/{slug}/export-pack/qbo
GET /api/v1/orgs/{slug}/export-pack/hubspot
GET /api/v1/orgs/{slug}/export-pack/asana
GET /api/v1/orgs/{slug}/export-pack/{target}

Schema routes:

GET /api/v1/orgs/{slug}/export-pack/qbo/schema
GET /api/v1/orgs/{slug}/export-pack/hubspot/schema
GET /api/v1/orgs/{slug}/export-pack/asana/schema
GET /api/v1/orgs/{slug}/export-pack/{target}/schema

Native service routes

Native routes emulate provider-shaped APIs for selected systems.

Public catalog snapshots observed on October 28, 2026 list 60 entries in both staging and production. They mark 59 entries available/selectable with native support and one FCI execute preview as not selectable; all entries report approximate fidelity. These catalog values do not verify individual requests or promise strict upstream parity. The published first-request templates were tested in staging only. Use the provider directory for exact paths, POST bodies, content types, and catalog status, and the workflow reference for staging-verified operations.

Before calling a provider/object route, query the public Capability Matrix and catalog object-schema endpoint. The company and selected services determine whether a path has native, generic, or no support.

Native routes also require the native.genome entitlement. The Console shows the active plan and feature availability for the organization that owns the company.

The routing pattern is:

/api/v1/orgs/{slug}/native/{service}/{provider_path}

provider_path can include API versions, account IDs, a GraphQL endpoint, an XML gateway, or a form endpoint. It is not a universal object CRUD path. For example:

GET /api/v1/orgs/{slug}/native/stripe/v1/customers
GET /api/v1/orgs/{slug}/native/qbo/v3/company/test/query?query=SELECT%20*%20FROM%20Customer
POST /api/v1/orgs/{slug}/native/monday/v2
POST /api/v1/orgs/{slug}/native/sage_intacct/ia/xml/xmlgw.phtml

Use the canonical provider ID qbo for QuickBooks requests. Native reads need read; native writes need write. Some reads use POST. Writes require a nonempty idempotency key. Send a fresh Idempotency-Key header for each operation, unless the provider workflow documents another header or body field for that route. Reuse the key only when retrying the same operation and payload. Inspect provider-level errors as well as HTTP status.

Choosing demo jobs vs runtime routes

Use /demo-jobs when:

• you are creating companies
• you want normalized data
• you need the stable partner contract
• you need quality/certificate/readiness metadata
• you do not want to manage runtime API keys

Use runtime routes when:

• your product specifically needs X-API-Key isolation
• you are testing provider-shaped API behavior
• you need raw export packs
• you are building internal tooling against generated companies

Key lifecycle

Project API keys are created, rotated, and revoked in the Console. They are scoped to a single generated company. If a key is exposed, rotate it in the Console and update your server-side secret before revoking the old key.

Never use an X-Admin-Key or a project key in frontend JavaScript. The Console is the frontend entry point; runtime keys belong only in server-side workloads.