Skip to content
Esc
↑↓navigate↵open⌘Jpreview
On this page

Introduction

Authentication, endpoint families, billing, response headers, and error behavior for the QuiverAI API.

This reference covers the HTTP API at api.quiver.ai. Start with the Quickstart to configure an API Platform project and key before using the endpoint schemas.

Authentication

The QuiverAI API uses API keys with bearer authentication. Create and manage keys in API Keys, keep the secret server-side, and load it from an environment variable or secret manager.

Authorization: Bearer <QUIVERAI_API_KEY>

Use a project key for inference and model-catalog endpoints. Organization reads require an organization admin key with the endpoint’s organization permission. A project key’s * does not include organization permissions, and admin keys cannot run inference. Admin keys have no project or Test/Production environment. See API keys for scope and ownership.

Send requests to https://api.quiver.ai/v1. JSON requests also require:

Content-Type: application/json

Choose an endpoint family

Responses API

Use POST /v1/responses with a catalog model that supports open_responses when your application provides functions or custom tools for Arrow to call. Responses uses Open Responses request, response, and SSE event shapes. Your application handles function_call or custom_tool_call items and replays their results to continue the conversation; the API does not execute those tools.

Responses requests are stateless: set store: false or omit it. Stored response retrieval and non-null previous_response_id values are not supported. Replay earlier input and output items in input to continue a conversation. Use HTTP requests or SSE streaming; WebSockets are not supported.

See Current limitations before adapting an existing Responses client, and SDK compatibility for provider configuration.

A Test key calls the Responses API against the sandbox rather than a model. Confirm model availability and key authority before routing an integration to it. See Migrate to the Responses API for the conditional migration path.

Native SVG endpoints

The native endpoints remain supported and are the narrower contract when the operation is already known:

  • POST /v1/svgs/generations
  • POST /v1/svgs/vectorizations
  • POST /v1/svgs/edits
  • POST /v1/svgs/animations

Use GET /v1/models and GET /v1/models/{model} to discover the catalog and the operation and billing capabilities available to the organization. The key must also authorize the requested model and operation; appearing in the catalog does not grant access.

Streaming and final results

Native SVG streams use reasoning, draft, and final content events. Responses streams use OpenResponses events. In both cases, data: [DONE] ends the transport; it is not itself proof of a successful final result. Do not persist preview output as an authoritative SVG.

For terminal event and retry handling, see Errors and debugging. To keep the SVGs that finished when other outputs in the same request fail, see Partial batch results.

Billing and usage

Read each model’s billing.kind from GET /v1/models or GET /v1/models/{model} before calculating cost:

  • Fixed-credit models publish per-operation pricing_credits. Generations debit svg_generate for each SVG returned; successful vectorizations debit svg_vectorize once per request. Other supported operations use their corresponding catalog rate. When some conversions in a batch fail, data can hold fewer than n SVGs, and a stream can deliver its completed SVGs and then an error event.
  • Token-priced models publish billing.rates and settle validated terminal token usage. Each Responses request in a tool loop is metered separately.

API Platform usage draws from the organization’s prepaid on-demand balance, not from App subscription credits. Manage the API balance and automatic top-up in API Platform Billing, review estimated attribution in Usage, and see API pricing for billing details.

Response headers

Every response includes X-Request-ID. Preserve it for request correlation and support.

You can send an optional caller trace id in x-trace-id. The API echoes it in X-Trace-ID for correlation with your own telemetry.

Capacity rejections can include:

  • X-RateLimit-Limit and X-RateLimit-Remaining for the reported window;
  • X-RateLimit-Reset when a fixed reset time applies;
  • X-RateLimit-Scope and optional X-RateLimit-Subject for the rejecting scope;
  • X-RateLimit-Dimension for request, operation, input-token, or output-token capacity;
  • Retry-After when retry timing is available.

Responses authenticated with an API Platform key also carry the complete data-posture header set when tenant and project attribution succeeds. See Data controls for those headers.

Errors and rate limits

Error responses carry status, code, message, and request_id. Use the machine-readable status and code for control flow, and retain the request ID. A /v1/responses stream that fails after it starts reports them inside the error object of its event: error frame, with status as error.status_code; the native SVG streams report the envelope as it is. The Errors and debugging guide contains the status/code matrix, rate-limit behavior, streaming failures, Logs workflow, and support escalation checklist.

When funding is insufficient, resolve it in API Platform Billing. When capacity rejects a request, review API Platform Limits.

SDKs

QuiverAI provides an official Node.js SDK:

npm install @quiverai/sdk

You can also use the official OpenAI JavaScript and TypeScript SDK by setting QuiverAI as the base URL:

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.QUIVERAI_API_KEY,
  baseURL: "https://api.quiver.ai/v1",
});

const response = await client.responses.create({
  model: "arrow-2",
  input: "Create a minimal geometric compass icon in blue.",
  store: false,
});

The Open Responses endpoint is also verified with the Vercel AI SDK’s @ai-sdk/open-responses provider for streaming and non-streaming tool loops:

import { createOpenResponses } from "@ai-sdk/open-responses";

const arrow = createOpenResponses({
  name: "quiver",
  url: "https://api.quiver.ai/v1/responses",
  headers: {
    Authorization: `Bearer ${process.env.QUIVERAI_API_KEY}`,
  },
})("arrow-2");

Other Open Responses clients can target the same endpoint when they support a custom URL and bearer headers. For other integrations, call the REST API directly.

Was this page helpful?