Skip to content

Build on Venturi

The Venturi developer platform exposes the same attribution graph that powers the dashboard as a first-class, versioned API. Read attributed cost, energy, and carbon; create exports; manage budgets, API keys, and webhooks; and stream attribution events into your own tooling — all over a stable REST contract with typed SDKs, a sandbox, and a deprecation policy designed to operate for years without breaking downstream systems.

Venturi deploys a dedicated data plane inside your trust boundary. The API runs on your instance, every response is tenant-scoped, and no prompt or completion content is ever stored or returned — attribution results carry metadata, evidence, and confidence, never the underlying AI content.

What you can build

Goal Surface
Push AI inference events into the attribution pipeline Ingestion API
Read attributed cost / energy / carbon for chargeback REST API — GET /api/v1/attribution, /coverage
Generate FOCUS-aligned chargeback exports REST API — POST /api/v1/exports
React to attribution, coverage, budget, and connector events Webhooks
Ship integrations in TypeScript or Python SDKs
Develop and test against synthetic data Sandbox
Plan for limits, versions, and deprecations Versioning & rate limits

The surfaces

Venturi exposes three API surfaces. As a customer engineer you build against the public API; partners building marketplace integrations use the partner API under the same lifecycle and deprecation guarantees.

Surface Audience Base path Lifecycle
Public API Your engineers and FinOps teams /api/v1 ≥12-month deprecation window
Partner API iPaaS / connector / marketplace partners /api/partner/v1 Same lifecycle; partner-scoped tokens
Webhooks Any consumer reacting to events Your endpoints Event catalog under the same back-compat discipline

Base URL

Because Venturi runs inside your environment, the base URL is your deployed instance — for example https://<your-venturi-instance>. Your onboarding contact provides the exact host. Every path in these pages is relative to that host.

Core principles

The developer platform is built on a small set of guarantees you can design against:

  • Read-only by default. Connectors and integrations read; they never write to your AI systems. Attribution observes consumption — it never sits in the request path of your AI traffic.
  • Fail-open never blocks your AI. Customer AI traffic is never gated by Venturi. Attribution that cannot be resolved is reported honestly (see confidence and evidence) rather than guessed. Control-plane operations — authentication, authorization, tenant isolation, exports, and billing — fail closed.
  • No content capture. Request and response bodies of your AI calls are never stored. Error and event payloads are scrubbed of any content keys.
  • Every result is explainable. Attribution responses carry an evidence card: which pipeline stage produced the result, its confidence band, the evidence basis, the model version, the current degradation state, and data freshness.
  • Stable for years. Within a major version no field is removed, renamed, retyped, or narrowed, and no closed enum loses a member. Breaking changes ship as a new major version served in parallel.

A first call

Every read is authenticated and tenant-scoped. The smallest useful call lists recent attribution records:

curl https://<your-venturi-instance>/api/v1/attribution?limit=5 \
  -H "Authorization: Bearer $ARGMIN_TOKEN"

{
  "data": [
    {
      "id": "attr_01HF8...",
      "invocation_id": "inv_01HF8...",
      "provider": "openai",
      "served_model": "gpt-4o",
      "cost_usd": 0.0142,
      "output_state": "attributed",
      "interpretation": {
        "stage_origin": "stage_b",
        "confidence": 0.91,
        "confidence_band": "high",
        "evidence_basis": "identity_resolved",
        "model_version": "rail-2025.11",
        "degradation_state": "none",
        "freshness": "fresh",
        "export_eligibility": "eligible"
      }
    }
  ],
  "page": { "next_cursor": "eyJ...", "limit": 5, "has_more": true }
}

Continue to the REST API reference for authentication, scopes, pagination, idempotency, and the full error model.

Where to go next

  • REST API — auth, scopes, pagination, errors, idempotency.
  • Webhooks — events, signing, verification, retries.
  • SDKs — TypeScript and Python clients.
  • Sandbox — test mode against synthetic data.
  • Versioning & rate limits — limits, versions, and deprecation.