🔌 OpenAI SDK compatible

$5 Free Credits
for your OpenAI-powered app

Same OpenAI SDK. Different network underneath. Image generation, TTS, transcription and embeddings — change base_url, ship today.

Same SDK No code rewrite No credit card required

Why teams swap base_url

Compatibility is the boring part. The interesting part is what it unlocks once your code keeps working.

Five-minute migration

One parameter at client init. Your retry logic, error handlers, schemas and tests come along unchanged. No new SDK to learn, no new docs to write.

Lower bills, no lock-in

Open-weight models on a decentralized GPU pool. Capacity comes from independent operators competing on price — not a single vendor's hyperscaler invoice.

Modalities OpenAI doesn't ship

FLUX, Qwen Image, Z-Image, Kokoro TTS, Whisper Large V3, BGE M3 — the open-weight flagships, behind familiar OpenAI endpoints.

Sovereign by design

A distributed GPU pool across regions — a practical non-US default for European and APAC teams who don't want a single-jurisdiction inference path.

Two things change. Everything else stays.

The official OpenAI clients all accept base_url. So does every framework that wraps them. Pick your language — the diff is the same.

from openai import OpenAI

client = OpenAI(
    api_key="dpn-sk-your-token-here",
    base_url="https://oai.deapi.ai/v1",
)

# Image generation — same call as OpenAI
img = client.images.generate(
    model="Flux_2_Klein_4B_BF16",
    prompt="a neon-lit city at dusk, cinematic",
    n=1,
)

# Text-to-speech
audio = client.audio.speech.create(
    model="Kokoro",
    voice="af_bella",
    input="Welcome to a different kind of inference.",
)

# Embeddings
emb = client.embeddings.create(
    model="Bge_M3_FP16",
    input="text to embed",
)
import OpenAI from "openai";

const client = new OpenAI({
  apiKey: "dpn-sk-your-token-here",
  baseURL: "https://oai.deapi.ai/v1",
});

const img = await client.images.generate({
  model: "Flux_2_Klein_4B_BF16",
  prompt: "a neon-lit city at dusk, cinematic",
});

const tx = await client.audio.transcriptions.create({
  model: "WhisperLargeV3",
  file: fs.createReadStream("meeting.mp3"),
});
# Image generation
curl https://oai.deapi.ai/v1/images/generations \
  -H "Authorization: Bearer dpn-sk-your-token-here" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "Flux_2_Klein_4B_BF16",
    "prompt": "a neon-lit city at dusk, cinematic",
    "n": 1
  }'

# Transcription (Whisper Large V3)
curl https://oai.deapi.ai/v1/audio/transcriptions \
  -H "Authorization: Bearer dpn-sk-your-token-here" \
  -F file="@meeting.mp3" \
  -F model="WhisperLargeV3"
from langchain_openai import OpenAIEmbeddings

# Anything that wraps the OpenAI client accepts base_url.
embeddings = OpenAIEmbeddings(
    model="Bge_M3_FP16",
    api_key="dpn-sk-your-token-here",
    base_url="https://oai.deapi.ai/v1",
)

vector = embeddings.embed_query("deAPI is OpenAI-compatible")

# Same idea for LlamaIndex, CrewAI, AutoGen, Instructor, Vercel AI SDK.
# Wherever the framework calls the OpenAI provider, point base_url at deAPI.
package main

import (
    "context"
    openai "github.com/openai/openai-go"
    "github.com/openai/openai-go/option"
)

func main() {
    client := openai.NewClient(
        option.WithAPIKey("dpn-sk-your-token-here"),
        option.WithBaseURL("https://oai.deapi.ai/v1"),
    )

    img, _ := client.Images.Generate(context.TODO(), openai.ImageGenerateParams{
        Model:  openai.F("Flux_2_Klein_4B_BF16"),
        Prompt: openai.F("a neon-lit city at dusk"),
    })
    _ = img
}
using OpenAI;
using OpenAI.Images;

var client = new ImageClient(
    model: "Flux_2_Klein_4B_BF16",
    credential: new ApiKeyCredential("dpn-sk-your-token-here"),
    options: new OpenAIClientOptions {
        Endpoint = new Uri("https://oai.deapi.ai/v1")
    });

var result = await client.GenerateImageAsync("a neon-lit city at dusk");

Same authentication header. Same response shapes. Same retry semantics. The only thing your code learns is the new hostname.

If it accepts base_url, it works with deAPI.

You don't have to wait for an integration. The official OpenAI clients and every modern agent framework are already integrations.

Official OpenAI SDKs

  • Python (openai-python)
  • Node / TypeScript
  • Go (openai-go)
  • .NET (OpenAI for .NET)
  • Java (openai-java)

Maintained by OpenAI. SDK upgrades are someone else's problem.

Agent & RAG frameworks

  • LangChain
  • LlamaIndex
  • CrewAI
  • AutoGen
  • Instructor
  • Vercel AI SDK

Each accepts base_url on its OpenAI provider. Point it at deAPI — done.

What's compatible — and what isn't.

deAPI is a media inference layer. We don't proxy LLMs. Most teams keep OpenAI for chat and route media calls to deAPI from the same client.

OpenAI endpoint deAPI Open-weight models
/v1/images/generations ✓ Drop-in FLUX.2 Klein · Qwen Image · Z-Image Turbo
/v1/audio/speech ✓ Drop-in Kokoro · QwenTTS · Chatterbox
/v1/audio/transcriptions ✓ Drop-in Whisper Large V3
/v1/embeddings ✓ Drop-in BGE M3
/v1/chat/completions — Not in scope Keep this on OpenAI

Native deAPI is async-first — long jobs return a request_id and you choose how to collect the result: polling, webhook callback or a WebSocket connection. The OpenAI-compat gateway at oai.deapi.ai/v1 waits for you behind the scenes, so your existing OpenAI client gets the finished result in one sync call.

Multi-provider pattern

Two clients. Same SDK.

Keep OpenAI for GPT and reasoning. Route image, speech, transcription and embeddings through deAPI — from the same library, in the same file. The architectural pattern of the next two years.

  • One mental model — one SDK, two endpoints
  • Per-modality cost optimization, no rewrites
  • Easy fallback path between providers
app.py
from openai import OpenAI

# Chat — OpenAI
chat = OpenAI(api_key="sk-...")

# Media — deAPI (same SDK, different base_url)
media = OpenAI(
    api_key="dpn-sk-your-token-here",
    base_url="https://oai.deapi.ai/v1",
)

reply = chat.chat.completions.create(
    model="gpt-5",
    messages=[{"role":"user", "content":"Describe this scene."}],
)

picture = media.images.generate(
    model="Flux_2_Klein_4B_BF16",
    prompt=reply.choices[0].message.content,
)

voice_over = media.audio.speech.create(
    model="Kokoro",
    voice="af_bella",
    input=reply.choices[0].message.content,
)

From OpenAI to deAPI in three steps

Total time: less than the next stand-up.

1

Get your deAPI key

Sign up and copy your API key from the dashboard. New accounts get $5 in free credits — no card required.

2

Switch base_url

Initialize your OpenAI client with base_url="https://oai.deapi.ai/v1" and your deAPI key. The SDK passes the key as a Bearer token automatically.

No SDK swap. No new error types. No new auth shape.

3

Ship

Run your existing tests. Image, TTS, transcription and embeddings calls now hit deAPI's decentralized GPU network. Need to roll back? Switch base_url back. There is no lock-in.

Frequently asked questions

The questions every team asks before they switch.

For image generation, text-to-speech, transcription and embeddings — yes. Initialize the official OpenAI SDK with deAPI's base_url and your deAPI API key, and the same calls work without code changes. deAPI does not host LLMs, so chat completions stay on OpenAI.
/v1/images/generations, /v1/audio/speech, /v1/audio/transcriptions and /v1/embeddings are OpenAI-compatible on the gateway at oai.deapi.ai/v1. /v1/chat/completions is intentionally out of scope — deAPI is a media inference layer, not an LLM provider. Most teams keep OpenAI for chat and route media calls to deAPI from the same client.
No. You keep the official OpenAI SDK in Python, Node/TypeScript, Go, .NET or Java. The only change is the base_url parameter at client init. Your retry logic, error handlers, schemas and tests stay the same. The SDK still uses the same Authorization: Bearer … header — your deAPI key just goes in instead of an OpenAI key.
Yes. Any framework that accepts a base_url on its OpenAI provider — LangChain, LlamaIndex, CrewAI, AutoGen, Instructor, Vercel AI SDK — works with deAPI. Point the OpenAI provider inside the framework at deAPI and the framework's media tools start using deAPI immediately.
Yes — and most teams do. Instantiate two OpenAI clients with different base_urls in the same codebase: one for chat (OpenAI), one for image / audio / embeddings (deAPI). The SDK is identical, so there is no second integration to maintain.
For supported endpoints, deAPI returns OpenAI-compatible response shapes — your existing parsers, types and schemas keep working.
Two reasons. The models are open-weight — image, audio and embedding flagships like FLUX, Qwen Image, Kokoro and BGE M3 are commodities the GPU pool can run, not closed checkpoints with a brand premium. And the GPU supply is decentralized — capacity comes from a global pool of independent operators competing for inference work, not centrally-owned hyperscale hardware.
Yes. The decentralized GPU network spans regions, which makes deAPI a practical alternative to US-centric inference providers for European and Asian teams who need a non-US default for media workloads.
Streaming, polling, webhook callbacks and WebSocket delivery map to the OpenAI client's built-in flows for the supported endpoints. For long-running media jobs deAPI also exposes a unified job-status pattern across modalities — see the migration guide in the docs.
Create a free deAPI account, copy your API key, and pass it to the OpenAI client together with base_url="https://oai.deapi.ai/v1". New accounts receive $5 in free credits — no card required.

Stop migrating.
Just switch base_url.

Your OpenAI SDK. A decentralized GPU network. $5 in free credits to prove the integration is exactly as boring as we say it is.

Same SDK No subscription No credit card required