NNyquest docs

Developer API Overview

Nyquest exposes an HTTP API at https://api.nyquest.ai. This article covers what's available, what's not, and how to think about the API surface vs the chat UI.

What you can do via API

CapabilityEndpoint family
Chat completions (OpenAI-compatible)POST /v1/chat/completions
List available modelsGET /v1/models
Image generationPOST /v1/image/generate
Audio / TTS generationPOST /v1/audio/generate
Agent runs (multi-step with tools)POST /v1/agents/run, GET runs, stream events
Live market quotes (Quant chassis ticker)GET /v1/quotes
Live support sessionsPOST /v1/support/sessions etc.
Account infoGET /user/me, GET /user/stats
Manage projects, conversations, BYOK providers/user/... family
Manage personal API keysPOST /user/api-keys, list, delete
BillingGET /billing/account, /billing/ledger, /billing/usage

The API mirrors what the web UI does — anything you can do clicking around the dashboard, you can do via HTTP.

What's NOT in the API

Currently there is no:

  • MCP server interface. Nyquest's backend doesn't expose itself as an MCP server. (You can use external MCP servers — that's a Chrome-extension / agent-mode tool integration, not a Nyquest endpoint.)
  • Outbound webhooks. Nyquest doesn't push events to your URLs (no "notify me when an agent run completes" hooks). The Stripe billing webhook (/billing/webhook) is INBOUND only — it's how Stripe tells Nyquest when a payment lands, not a user-facing feature.
  • Bulk operations. No batch chat completions, no batch image generation. One request at a time.
  • WebSocket interface. Streaming is over Server-Sent Events (SSE), not WebSocket.
  • GraphQL. REST + JSON only.
  • Embedding endpoint. The platform uses embeddings internally (memory recall, artifact search) but doesn't expose /v1/embeddings for direct client use yet.

If any of these matter, talk to a real human.

Two compatibility levels

OpenAI-compatible

POST /v1/chat/completions accepts standard OpenAI request shape and returns standard OpenAI response shape. Drop-in for any tool that already targets OpenAI:

javascript
const openai = new OpenAI({
  apiKey: 'nq-v1-...',
  baseURL: 'https://api.nyquest.ai/v1',
});

You get streaming, model selection, system/user/assistant messages, all the standard fields. The platform routes to whichever provider serves the model you picked.

Nyquest-specific

Other endpoints (/v1/agents/run, /v1/quotes, /user/...) are platform-specific. Documented per-endpoint in the Endpoints Reference.

Auth in one sentence

Every authenticated endpoint takes a Authorization: Bearer <token> header where <token> is either a JWT (from sign-in flow) or a personal API key (from /user/api-keys). See Authentication.

API key requests are stateless

This is a behavioral difference between API key (nq-...) requests and JWT (browser sign-in) requests that's worth knowing up front.

Requests authenticated via API key:

  • Do not create a conversation in your web-UI chat history.
  • Do not store user or assistant messages anywhere persistent.
  • Do not inject prior context (memory recall is skipped).
  • Do not honor the x-nyquest-conversation header — it's ignored.
  • Do continue to track usage and bill normally via the same usage ledger.

Requests authenticated via JWT (web UI sessions):

  • Create / resume conversations in your chat history.
  • Persist messages, surface them in the dashboard, run memory recall.
  • Honor x-nyquest-conversation to pick up an existing thread.

Why it works this way

This mirrors industry-standard developer-API behavior (OpenAI, Anthropic, Stripe). The intuition: web UIs are for humans, who want their conversations remembered. APIs are for programs, which manage their own state. If your client wants conversation continuity over an API key, build it the way every other LLM SDK builds it — append {role, content} objects to the messages array on the next request.

What this prevents

If you build an integration against app.nyquest.ai using an API key, those requests stay invisible in the dashboard owner's chat history. No accidental cross-contamination between a programmatic backend and the human's chat surface. No "why are there 300 conversations I don't recognize" surprises.

What this means for billing

Nothing — every API request still records a usage_events row with token counts and cost. You'll see API usage in /billing/usage and /user/stats exactly like web usage. The only difference is conversation_id will be NULL on those rows.

Rate limits in one sentence

Free tier: 20 requests per minute on chat. Pro tier (after first wallet funding): 120 per minute on chat. Auth endpoints: 5 per minute per IP. See Rate Limits and Quotas.

What this is good for

  • Custom integrations. Wire Nyquest into your own tools without going through the web UI.
  • Automation. Scripts that send recurring queries, batch translation, scheduled summaries, etc.
  • Testing. Run prompts programmatically, compare outputs across models.
  • Server-side use. Your backend calls Nyquest, which routes to the right model, with platform features (memory, BYOK) applied.

What this is NOT good for

  • Reselling Nyquest's API. Our terms don't permit white-labeling.
  • Replacing your direct provider integration. If you only want one model and don't need memory / agent mode, going direct to OpenAI or Anthropic is simpler.
  • High-throughput batch (1000+ req/s). The platform is sized for interactive use, not batch ETL workloads.

Where to next