Skip to main content
Zunova

Zunova AI API

OpenAI-compatible API gateway for chat completions, coding tools, and model access.

What is Zunova?

Zunova is a production gateway that lets your app call AI models through one controlled API layer. It centralizes API keys, model access, request logging, quota enforcement, and provider routing so teams can ship AI features without exposing provider credentials directly.

  • Use OpenAI-compatible clients where possible.
  • Keep provider credentials server-side behind the gateway.
  • Track requests, latency, tokens, cost, and errors from the dashboard.
  • Apply plan-based daily and per-minute request limits automatically.

Base URLs

Use the OpenAI-compatible proxy base URL for SDKs that append /chat/completions automatically. Use the full endpoint URLs when sending raw HTTP requests.

PurposeURL
General API base URLhttps://api.zunova.net/v1
OpenAI-compatible proxy base URLhttps://api.zunova.net/open/v1
Chat completion endpointhttps://api.zunova.net/open/v1/chat/completion
Chat completions aliashttps://api.zunova.net/open/v1/chat/completions
Model list endpointhttps://api.zunova.net/open/v1/models
Anthropic-compatible URL, if enabledhttps://api.zunova.net/anthropic/v1
Health checkhttps://api.zunova.net/health

Quickstart

  1. Create an API key from Dashboard → Keys.
  2. Store the key in a server-side environment variable such as ZUNOVA_API_KEY.
  3. Send a POST request to /open/v1/chat/completions or configure your SDK baseURL to /open/v1.
  4. Check Dashboard → Requests for status, latency, token usage, cost, and error details.
export ZUNOVA_API_KEY=sk-zn-xxxx

First request

curl https://api.zunova.net/open/v1/chat/completions \
  -H "Authorization: Bearer $ZUNOVA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "zunova-m1",
    "messages": [
      { "role": "system", "content": "You are a concise assistant." },
      { "role": "user", "content": "Write one sentence about API gateways." }
    ]
  }'

Request lifecycle

Every authenticated request passes through validation, quota checks, provider routing, upstream execution, and dashboard logging.

  1. The gateway reads the Bearer token and validates the API key.
  2. Plan guardrails are checked before the upstream request is sent.
  3. The model identifier is validated against active public models when available.
  4. The request is proxied to the configured upstream provider with a generated x-request-id.
  5. The response is returned to the client while request metadata is written to logs.

On this page