> For the complete documentation index, see [llms.txt](https://anyint.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://anyint.gitbook.io/docs/api-reference/overview.md).

# overview

This section is organized around the currently published API catalog behind `https://gateway.api.anyint.ai`. The most important distinction is that AnyInt exposes more than one compatibility family. Some routes are OpenAI-style, some are Anthropic-style, some are Gemini-native, and media and music workflows are task-oriented.

## Current endpoint families

| Family               | Routes                                                          | Best for                                   |
| -------------------- | --------------------------------------------------------------- | ------------------------------------------ |
| OpenAI-compatible    | `/openai/v1/chat/completions`                                   | Existing OpenAI SDK clients                |
| Models API           | `openai/v1/models`                                              | Discovering available models               |
| Anthropic-compatible | `/anthropic/v1/messages`, `/anthropic/v1/messages/count_tokens` | Claude-style clients and token counting    |
| Gemini-compatible    | `...generateContent`, `...streamGenerateContent`                | Gemini-native request shapes               |
| Media APIs           | DashScope image and video routes                                | Image and video generation                 |
| AI Music             | `/suno/*`                                                       | Music generation and async media workflows |

## Authentication patterns

The published routes currently use two header styles depending on the family:

* Bearer auth: `Authorization: Bearer <API_KEY>`
* Provider-style auth: `x-api-key: <API_KEY>` with any required compatibility headers such as `anthropic-version`

Use the header convention documented on the page for the endpoint family you are integrating.

## Recommended integration order

1. Start with [OpenAI Compatible API](/docs/api-reference/openai-compatible.md) if you only need chat or streaming.
2. Call [Models API](/docs/models-and-modalities/models.md) before shipping a hardcoded model ID.
3. Switch to [Anthropic Compatible API](/docs/api-reference/anthropic-compatible.md) or [Gemini Compatible API](/docs/api-reference/gemini-compatible.md) when you need a provider-native request body.
4. Use [Media APIs](/docs/api-reference/media-apis.md) and [AI Music](/docs/ai-music/overview.md) for asset-generation workflows that are not plain chat completions.

## Async vs synchronous routes

### Synchronous or stream-first

* OpenAI-compatible chat
* Anthropic messages
* Gemini text and image generation
* DashScope image generation

### Task-based

* DashScope video generation
* All AI Music workflows

Task-based APIs usually return a task ID first. You then poll a query endpoint or receive a webhook callback. Do not treat the initial `200` response as the final asset.

## A practical rule for choosing an API family

Use the OpenAI-compatible route if:

* you want the quickest first integration
* your app already uses the OpenAI SDK
* you do not need provider-native request fields

Use provider-native routes if:

* you need Anthropic content blocks or token counting
* you need Gemini `generateContent`, `streamGenerateContent`, or `functionDeclarations`
* you want to mirror the provider's native request format inside your own product

Use media or music routes if:

* the output is an image, video, or song rather than a plain text response
* the workflow is naturally asynchronous
* you need task polling or webhook callbacks