How do you build Arabic AI with an OpenAI-compatible API?

Key facts

Compatibility	Arabic and mixed-language prompts use the standard OpenAI-compatible chat completions endpoint
Models	30+ models in one catalogue; verify Arabic quality per model on your own set
Embeddings	plugsky-embed-multilingual for Arabic semantic search and clustering
Structured output	JSON mode and function calling are live for Arabic extraction tasks
Pricing model	Flat monthly self-serve plans with unlimited fair-use usage
Free tier	Free plan with 2 free AI models, no card required
Deployment	Cloud, VPC, on-prem and air-gapped options for regional requirements
Roadmap	Audio (speech) endpoints are coming soon

TL;DR

• No Arabic-specific endpoint exists: the same chat completions call serves Arabic.
• Normalize Arabic input yourself; the API will not unify letter variants for you.
• Pick and verify a multilingual model per task instead of defaulting to one alias.
• Use JSON mode for Arabic extraction and validate field values, not just JSON syntax.
• Keep RTL rendering and digit formatting in your UI layer, not in prompts alone.

How it works, step by step

1. Change the base URL to Plugsky and confirm an existing English request works unchanged.
2. Add a normalization helper for Arabic input and apply it before classification or caching.
3. Select a multilingual model alias and run your own Arabic evaluation set against two candidates.
4. Use JSON mode with a schema for Arabic field extraction, and validate values against business rules.
5. Format responses for right-to-left display, isolating Latin identifiers and numbers.
6. Log language, dialect and model per request so quality regressions are traceable.

Try it yourself

Open the OpenAI-compatible API tester →

What compatibility covers, and what it does not

An OpenAI-compatible API guarantees the request and response shape, not language quality. You get the same /v1/chat/completions contract, the same streaming format and the same JSON mode behaviour for Arabic text. What you do not get is automatic normalization of Arabic spelling variants, dialect detection, or promised quality per dialect.

That division of labour is healthy: the API handles transport and model access across 30+ models, while your application handles input cleaning, model selection and evaluation. Treat Arabic quality as a product decision you measure, not an API feature you assume.

Integration details for Arabic products

The changes that matter are small and local:

• Normalize: unify alef and ya forms, strip diacritics and tatweel, standardize digits and whitespace before classification or caching.
• Prompt: state the target variety — Modern Standard Arabic or a named dialect — and include an example response.
• Model: test candidates such as a multilingual general model versus a larger reasoning alias on your own prompts.
• Structure: use JSON mode for extraction with Latin field names; keep Arabic in the values.
• Streaming: stream as usual, but buffer enough text to avoid reordering artifacts in right-to-left rendering.
• Digits: choose Arabic-Indic or Western numerals and apply the choice consistently in code.

Evaluating Arabic quality

Build the evaluation set before the feature. Minimum coverage:

• Questions in Modern Standard Arabic plus the dialects you serve.
• Code-switching cases where users mix Arabic and English technical terms.
• Named entities, dates and monetary amounts, checked for exact preservation.
• Structured outputs, validated field by field rather than by JSON syntax alone.
• Refusals and clarifications on ambiguous input, which protect trust more than confident guesses.

Score candidates on the same set and keep the winning alias pinned per task. Re-run the set when you change models or prompts, because multilingual quality shifts between catalogue versions.

Limitations

Be explicit about what this stack cannot do yet:

• Arabic speech-to-text and text-to-speech endpoints are coming soon, so voice products need separate tooling.
• Dialect coverage varies; a model strong in Modern Standard Arabic can be weaker in Maghrebi or Gulf input.
• Arabic text often consumes more tokens per word than English, which affects context budgeting — measure on your corpus rather than assuming parity.
• Normalization improves matching but can alter meaning in domains that depend on diacritics; keep the original text.
• Residency and scoped-key rules still apply to Arabic workloads; language does not change compliance obligations.

Honest comparison

Capability	Arabic on Plugsky API	English API plus translation layer	Arabic-specific vendor API
Integration	Same OpenAI-compatible client	Two hops, two failure modes	New SDK and contract
Model choice	30+ models, pick per task	Whatever the English vendor offers	Single vendor catalogue
Structured output	JSON mode with Arabic values	Translation degrades structure	Varies
Embeddings	plugsky-embed-multilingual	English embeddings on translated text	Vendor-specific
Deployment	Cloud, VPC, on-prem, air-gapped	Vendor cloud	Varies

Frequently asked questions

Is there a special Arabic endpoint?

No. Arabic requests use the standard OpenAI-compatible chat completions endpoint; quality depends on the multilingual model you select and how you shape the prompt.

Which model should I choose for Arabic?

Evaluate at least two candidates from the catalogue on your own Arabic prompts. Task type matters more than brand: extraction, chat and reasoning may each want a different alias.

Does JSON mode work with Arabic values?

Yes. Field names can stay in Latin for downstream compatibility while values hold Arabic text. Validate the value semantics, not only the JSON syntax.

How do I handle mixed Arabic and English text?

Normalize Arabic portions, keep Latin identifiers intact, and include code-switching examples in the prompt and evaluation set.

Do I need to send a language parameter?

There is no required language parameter; state the target variety in the system prompt and keep it consistent across requests.

What about Arabic speech?

Audio endpoints are coming soon. Until then, pair Plugsky text models with a separate speech stack if you need voice input or output.

Can I test Arabic workloads for free?

Yes. The free plan includes two free models with no card, and the 14-day full-access trial lets you compare larger multilingual models on real Arabic data.