Token360
Sign Up

Overview

The Token360 API is OpenAI-compatible and follows RESTful conventions.

Base URL

https://api.token360.ai/v1

Authentication

All requests require an API key in the Authorization header:

Authorization: Bearer sk-your-api-key

Request Format

  • Content-Type: application/json for most endpoints. multipart/form-data for file uploads.
  • Method: POST for inference and creation, GET for retrieval, DELETE for deletion.

Example Request

Shell
1curl -X POST https://api.token360.ai/v1/chat/completions \
2  -H "Authorization: Bearer sk-your-api-key" \
3  -H "Content-Type: application/json" \
4  -d '{
5    "model": "glm-5.1",
6    "messages": [{"role": "user", "content": "Hello"}]
7  }'

Response Format

Successful responses return JSON with endpoint-specific data:

JSON
1{
2  "id": "your-chat-completion-id",
3  "object": "chat.completion",
4  "created": 1677652288,
5  "model": "glm-5.1",
6  "choices": [...],
7  "usage": {
8    "prompt_tokens": 10,
9    "completion_tokens": 20,
10    "total_tokens": 30
11  }
12}

Error responses follow a consistent format:

JSON
1{
2  "error": {
3    "message": "Description of the error",
4    "type": "error_type",
5    "param": null,
6    "code": "error_code"
7  }
8}

SDK Support

Token360 is compatible with the official OpenAI SDKs:

1# Python
2from openai import OpenAI
3client = OpenAI(api_key="sk-...", base_url="https://api.token360.ai/v1")

Any library or tool that supports custom OpenAI base URLs will work with Token360.

Native LLM endpoints

Token360 supports three LLM request styles:

  • POST /v1/chat/completions — OpenAI-compatible chat completions with Token360's normalized routing and response handling.
  • POST /v1/responses — OpenAI Responses API native passthrough for OpenAI/OpenAI-compatible providers. Stateless only: Token360 rejects previous_response_id, conversation, background: true, and explicit store: true.
  • POST /v1/messages — Anthropic Messages API native passthrough for Anthropic/Claude/Z.AI-compatible providers. Supports Authorization: Bearer sk-... and Anthropic-style x-api-key: sk-... platform authentication.

Native passthrough endpoints return provider-native JSON or SSE events. Token360 still handles API-key authentication, provider routing, provider-key injection, billing, statistics, and archive recording.

Batch jobs

Token360 exposes an OpenAI-compatible Batch API for asynchronous chat completions:

  • GET /v1/batches/models — list model names that support batch for your account
  • POST /v1/files (purpose=batch) + POST /v1/batches — submit a JSONL input file
  • GET /v1/batches/{batch_id} — poll status; download results via GET /v1/files/{file_id}/content

See Docs → Batch Jobs and the API Reference → Batches section. Use the OpenAI SDK with base_url=https://api.token360.ai/v1 and client.batches.* / client.files.create(..., purpose="batch").

Account balance

  • GET /v1/billing/balance — current spendable balance (wallet + credit) for the authenticated account

See API Reference → Billing → Get Account Balance.

API key management

Token360 provides OpenRouter-compatible API key management endpoints on /v1:

  • GET /v1/key — inspect the API key used by the current request
  • GET /v1/keys — list your API keys
  • POST /v1/keys — create a new API key
  • PATCH /v1/keys/{hash} — update an API key by hash
  • DELETE /v1/keys/{hash} — delete an API key by hash

See API Reference → API Keys. These endpoints do not use the backend R<T> envelope; they return OpenRouter-style JSON objects.

Vendor-native passthrough (Token360-Native-Params)

For POST /v1/videos, POST /v1/images/generations, and POST /v1/audio/speech, you may send supplier-native JSON instead of the normalized OpenAI-style body by setting:

Token360-Native-Params: true

The gateway still applies API-key auth, model → provider model id rewriting, and asset:// validation/replacement. See Docs → Native Params Passthrough for the full contract, endpoint matrix, and troubleshooting.

Was this page helpful?