canonical: https://jentic.com/apis/tabbyml.com/tabbyml

# Tabbyml Tabby Server

[![tabby stars](https://img.shields.io/github/stars/TabbyML/tabby)](https://github.com/TabbyML/tabby) [![Join Slack](https://shields.io/badge/Join-Tabby%20Slack-red?logo=slack)](https://links.tabbyml.com/join-slack) Install following IDE / Editor extensions to get started with [Tabby](https://github.com/TabbyML/tabby). * [VSCode Extension](https://github.com/TabbyML/tabby/tree/main/clients/vscode). The API exposes 4 endpoints secured with bearer authentication.

## For AI agents

Programmatically chat_completions, completion. Covers 4 operations with bearer authentication.

## Scope

Does not handle payments, communications, or crm - use for e-commerce only.

## Capabilities

- chat_completions
- completion
- event
- health
- Monitor Tabby Server operational status and events

## Use cases

### E-Commerce Operations

Use the Tabby Server to perform e commerce operations programmatically. The API provides 4 endpoints covering core functionality including chat_completions, completion, event.

Example prompt: Call POST `/v1/chat/completions` to chat_completions

### Automated Chat Management

Automate chat operations by combining multiple Tabby Server endpoints. Agents can completion and then event in a single workflow.

Example prompt: Call POST `/v1/completions` to completion, then verify the result

### AI Agent Integration via Jentic

AI agents discover and call Tabby Server endpoints through Jentic without managing credentials directly. An agent searches for the required operation by intent, receives the matching endpoint schema, and executes the call with Jentic-managed authentication. This eliminates the need to read API documentation or handle bearer tokens manually.

Example prompt: Search Jentic for 'chat_completions', load the operation schema, and execute with Jentic-managed credentials

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| POST | `/v1/chat/completions` | chat_completions |
| POST | `/v1/completions` | completion |
| POST | `/v1/events` | event |
| GET | `/v1/health` | health |

## Key resources

- **Chat** — Operations for chat
- **Completions** — Operations for completions
- **Events** — Operations for events
- **Health** — Operations for health

## AI readiness

This API is usable in Jentic One now. Its AI-readiness score against Jentic's framework shows where it stands today and where improvements would make it even easier for agents to use.

- **Score:** 0 / 100
- **Maturity:** Non-Ready
- **Dimensions:**
  - Foundational Compliance: 100 / 100
  - Developer Experience & Jentic Compatibility: 56 / 100
  - AI-Readiness & Agent Experience: 26 / 100
  - Agent Usability: 94 / 100
  - Security: 60 / 100
  - AI Discoverability: 0 / 100
- **View full report:** https://jentic.com/apis/tabbyml.com/tabbyml/scorecard
- **How the score is calculated:** https://docs.jentic.com/reference/api-readiness-framework/overview/
- **More about the dimensions:** https://docs.jentic.com/reference/api-readiness-framework/specification/#dimensional-model-overview

### Score it yourself

Every API in the directory is allowlisted, so you can re-score it with no key required.

- **Score your own API:** https://jentic.com/scorecard.md
- **Scoring CLI agent skill:** https://github.com/jentic/jentic-api-scorecard/blob/main/skills/jentic-api-scorecard/SKILL.md

```sh
npx @jentic/api-scorecard-cli score <openapi-url>
```

## Why Jentic

- **Setup:** Wiring Tabby Server by hand means learning its bearer token auth, pointing at the right host, and shaping completion and event requests yourself. Through Jentic you install once, import Tabby Server from the API Directory, store the token once, and your agent calls it.
- **Permission scoping:** Tabby's completion and event calls carry their target in the request body, so limit the agent to the operations it needs, such as chat completions or health checks, rather than to any one resource. Every operation the agent can run is one you chose to allow.
- **Credential handling:** Your Tabby Server token is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'complete a chat prompt' or 'check server health', and Jentic returns the matching Tabby Server operation with its input schema so the agent calls the right endpoint without browsing the reference docs.

## Related APIs

- **Shopify** — Alternative e commerce API
- **Stripe** — Alternative e commerce API

## FAQ

### What authentication does the Tabby Server use?

The Tabby Server uses a Bearer token in the Authorization header. Through Jentic, these credentials are stored encrypted in your Jentic One instance and injected at execution time, so raw secrets never enter the agent context.

### Can I chat_completions with the Tabby Server?

Yes. Use the POST `/v1/chat/completions` endpoint. The API returns structured JSON responses that agents can parse and act on directly.

### What are the rate limits for the Tabby Server?

Rate limits are not specified in the OpenAPI spec. Check the vendor documentation for current limits. Through Jentic, rate limiting is handled automatically with retry logic built into the execution layer.

### How do I chat_completions through Jentic?

Install the Jentic SDK with pip install jentic, authenticate through Jentic One, the self-hosted execution layer, then search for 'chat_completions'. Jentic returns the matching Tabby Server operation with its input schema. Load the schema and execute the call - credentials are injected automatically.

### How many endpoints does the Tabby Server have?

The Tabby Server exposes 4 endpoints covering chat, completions, events operations.

### Can I limit what my agent is allowed to do with the Tabby Server API?

Yes. Because you run Jentic One yourself, your own rules decide which Tabby Server operations the agent may call, so you can allow only chat completions and health checks while withholding completions or event writes. Tabby's completion and event requests carry their target in the request body rather than in a single resource path, so you scope access by operation rather than by resource. Every operation the agent can run is one you chose to allow, and the stored bearer token is injected at execution time without ever entering the agent's context.