Quantitative products, agents, platforms, and Connect APIs are open for approved institutional partners.
How to use QSentia Connect from approval to ingestion.
This guide is written for family offices, brokers, investment managers, and operations teams that want a clean path from agent diligence into controlled API ingestion.
Read-only first. Live gated later.
Review public evidence
Start in the agent marketplace. Backtest evidence, agent descriptions, and public sample results help the investment team decide which strategies are worth onboarding.
Submit the Connect application
Tell QSentia the organization, integration type, agent scope, expected API volume, and the workflow that will receive agent output.
Receive approval and keys
QSentia creates the customer record, assigns agent entitlements, sets request limits, and issues a scoped sandbox or production API key.
Pull agent outputs
The family office can pull entitled agents and latest signal payloads into research, portfolio monitoring, OMS, or internal risk dashboards.
Pull approved custom candidates
If the family office builds a Risk Studio mandate, QSentia can approve that candidate and expose it through the same Connect API without exposing private artifacts.
Register webhooks
Approved endpoints can receive signed signal, telemetry, order, and test events through QSentia Connect webhook delivery.
Monitor usage and audit
Portal views show key status, request activity, billing-meter rows, webhook deliveries, and audit events for operational review.
What a family office should complete before production use.
QSentia Connect is intentionally structured so the investment team, operations team, and technical team can each verify their part of the workflow before any live allocation step.
A named integration owner and technical owner are assigned.
Target agents and environment are defined: sandbox, paper, or live delivery.
API key is stored in a secret manager, never in source code or spreadsheets.
Sandbox and production keys use separate secrets, optional IP allowlists, expiry dates, and environment scopes.
Rate-limit headers are monitored by the receiving system.
Webhook receiver validates QSentia HMAC signatures before accepting payloads.
A test webhook is sent and logged before production delivery is enabled.
Scheduled webhook delivery is enabled only after the receiving endpoint has passed testing.
Usage billing rows are reviewed in record-only mode before billing sync is allowed to mark usage as reported.
Internal portfolio or OMS mapping records QSentia agent id, signal timestamp, and evidence id.
Usage billing and audit logs are reviewed weekly during rollout.
The minimum integration path.
/api/connect/v1/modelsList entitled agents, broker status, latest signal time, and live return context.
/api/connect/v1/models/{model_id}/latest-signalFetch the latest signal package for one entitled agent.
/api/connect/v1/custom-modelsList approved custom Risk Studio candidates entitled to the API key.
/api/connect/v1/custom-models/{candidate_id}/backtestFetch approved candidate backtest metrics, curve, and evidence summary.
/api/connect/v1/custom-models/{candidate_id}/latest-signalFetch the normalized latest custom candidate signal package.
/api/connect/v1/webhooksReview registered endpoints and delivery state.
/api/connect/v1/webhooksRegister a receiving endpoint for signed delivery.
/api/connect/v1/webhooks/testSend a test event through the delivery queue.
/api/connect/internal/scheduledQSentia-operated worker that sends queued webhooks and syncs usage billing.
Webhook receiver rule
Treat every webhook as untrusted until the timestamp and HMAC signature are verified against the signing secret shown once during endpoint registration.
signed_payload = timestamp + "." + raw_body expected = hmac_sha256(secret, signed_payload)
Credential handling
API keys should be scoped by environment and agent entitlement. Rotate keys from the QSentia admin console when ownership changes or a receiving system is replaced.
Sandbox first, production only after approval.
Connect is meant to make agent evidence and signal ingestion operationally clear, while keeping live usage gated by customer agreements, controls, and approval.
Sandbox access is read-only and designed for technical validation before production approval.
Production keys are issued only after QSentia approves agent scope, data use, usage limits, and operational ownership.
Custom agent candidates are private to the requesting customer and only appear after candidate approval plus explicit Connect entitlement.
Custom candidate API responses expose metrics, evidence summaries, and normalized signals, but not private artifact URIs, agent packages, or internal metadata.
Signals are not investment advice. Each receiving organization remains responsible for suitability, compliance, trading decisions, and downstream execution controls.
Live allocation or execution requires a separate production access agreement and explicit QSentia approval.
Customer data use, retention, redistribution, billing, and support terms are governed by the signed customer agreement.