Introduction

Welcome to the meinGPT Developer Guide. With the meinGPT API, you can safely and easily build your own applications with AI, without needing additional accounts and services. Additionally, many of the powerful features from the platform, such as assistants and workflows, are also available in the API.

API Overview

The meinGPT API provides programmatic access to:

• LLM responses and Embeddings
• Assistants
• Workflow execution
• Audio transcription

Quick Start

curl -X POST "https://app.meingpt.com/api/openai/v1/chat/completions" \
-H "Authorization: Bearer $MEINGPT_API_KEY" \
-H "Content-Type: application/json" \
-d '{
  "messages": [
    {"role": "user", "content": "Hello, meinGPT!"}
  ],
  "model": "gpt-4o-mini"
}'

Rate Limits

The meinGPT API has no limit on the number of concurrent (parallel) streaming requests. Instead, a token budget per minute is checked at three levels simultaneously:

• Per user: 125,000 tokens/minute by default
• Per organization: 250,000 tokens/minute by default (shared across all users in the organization)
• Per model (platform-wide): 500,000 tokens/minute by default, shared across every meinGPT organization using that model. For high-demand models (e.g. Claude Opus, Claude Sonnet), this platform-wide budget can be the limiting factor even when your own user- and organization-level usage is well within its own limits.

All limits use a rolling 60-second window and count combined input and output tokens. A 429 response's message field names which level was exceeded (user, organization, or global). A custom higher limit for an organization cannot currently be self-configured — contact us to discuss an adjustment.

In addition to the token budget, a coarse IP-based flood protection of currently around 1,000 requests/minute per IP address applies independently of the token budget. This is not relevant for normal usage, but it can trigger on top of the token limit for workloads that issue very many short, parallel requests (for example benchmark or agent workloads with many small turns).

Requests over the limit are not queued; they are rejected immediately with a 429 error. The response includes a Retry-After header (currently a fixed 60-second value) plus headers indicating the token limit, remaining budget, and reset time.

Error Handling

If a request can't be completed, the API returns a non-2xx HTTP status code. Common codes:

• 400 – Invalid request (e.g. unsupported parameter value, malformed input)
• 401 – Invalid or missing API key
• 403 – Model or completions API not enabled for the organization
• 429 – Rate limit reached (see Rate Limits above) - retry with backoff or switch to a different model
• 500 – Temporary error at the AI provider - retry after a short wait

A 200 status does not guarantee usable content. If the model's output is blocked by content filtering, the response is still 200 OK, but choices[0].message.content is null or empty and choices[0].finish_reason is "content_filter" (no tool_calls present in this case). Always check finish_reason in addition to the HTTP status code before treating a response as successful, and handle content_filter distinctly from a retryable error — retrying an unmodified request will not change the outcome.

When stream: true, responses are sent as Server-Sent Events (text/event-stream) with object: "chat.completion.chunk" events. Each chunk carries choices[0].delta.content for incremental text (or choices[0].delta.tool_calls for tool calls), with choices[0].finish_reason set to null until the final chunk. The final chunk has an empty delta and a resolved choices[0].finish_reason — "stop", "length", "tool_calls", or "content_filter" — followed by a closing data: [DONE] event. As with non-streaming responses, check finish_reason for "content_filter" before treating the stream as fully successful.

Error responses always include a JSON body, but in meinGPT's own shape — {"status": "error", "message": "..."} — rather than OpenAI's {"error": {"message": ..., "type": ..., "code": ...}} envelope. OpenAI-SDK-based tools that expect the OpenAI shape can fail to parse ours and surface it as an empty or "no body" error, even though a body was sent. Always check the HTTP status code first rather than relying on the parsed error object — but note a 200 status alone does not guarantee valid content (see above) — and implement retries with exponential backoff for 429 and 500 responses. For 429 responses specifically, honor the Retry-After header's wait time before applying backoff — it already reflects the exact remaining window (see Rate Limits above).

Support

If you need help with the API, contact us at support@meingpt.com or submit a request through our support portal↗.

Best Practices

• Always handle errors properly
• Implement exponential backoff for retries
• Cache responses when appropriate
• Monitor your usage to avoid limits