AI APIs in Iran: A Vendor-Neutral Guide for Companies and Developers

An Iranian company that wants a large language model inside its product, its support desk, or its document workflow eventually asks the same practical question: which AI API can we actually use, from here, without building the business on something that can be switched off? The short answer is that there is no single safe supplier. There is a small set of legitimate routes (a domestic AI API provider, a self-hosted open-weight model, and in limited cases a foreign platform whose terms genuinely permit your use), and the durable architecture puts all of them behind one interface that your team controls.

This guide is written for technical leads, CTOs, and developers in Iranian organisations who have to make that decision with evidence. It explains why the obvious foreign APIs are hard to use, what the domestic and self-hosted options really provide according to their own documentation, how to size hardware, how to compare cost without trusting a headline price, how to test Persian quality, and how to write client code that can change providers through configuration.

One boundary is deliberate. This guide does not explain how to bypass sanctions, geo-blocks, identity checks, or any provider's terms of service, and it does not recommend account resellers. Those shortcuts put your data, your accounts, and your continuity in the hands of an arrangement that can end without notice. Everything below is about options you can defend to your board, your auditors, and your customers.

Why foreign model APIs are hard to use from Iran

Four separate barriers stack up, and each one fails in a different way.

Provider policy. The major model providers publish the countries they serve, and Iran is not on those lists. OpenAI's supported countries and territories page does not include Iran and warns that accessing or offering access to its services outside the listed countries may lead to the account being blocked or suspended. Note the words "offering access": they reach intermediaries, not only end users. Anthropic's supported regions page likewise omits Iran and reserves the right not to serve entities whose majority ownership traces to countries outside its list. Google's Gemini API available regions page, last updated in April 2026, does not list Iran either.

Sanctions law. Behind those lists sits the US Iran sanctions program administered by the Treasury's Office of Foreign Assets Control, including the Iranian Transactions and Sanctions Regulations. The OFAC Iran sanctions page shows the program is active, with new designations as recently as September 2026. OFAC has issued general licences for certain personal-communications tools; whether any particular commercial API use could fall under one is a question for qualified counsel, and in practice the providers themselves list Iran as unsupported. The same framework also restricts exports of US-origin goods, which matters later when you plan to buy accelerators.

Payment and identity. Foreign API platforms bill through international card and banking rails and verify accounts against supported countries. Iranian-issued cards and accounts generally cannot complete that loop, which is why a grey market of intermediaries exists. That market is exactly the dependency this guide advises against.

The network itself. International connectivity from Iran is not guaranteed. Cloudflare's Q1 2026 disruption review records a nationwide shutdown that began on 8 January 2026, with traffic near zero until 21 January and fuller recovery from 27 January, then a second shutdown from 28 February in which access was restricted through whitelists and so-called white SIM cards. Cloudflare's May 2026 follow-up reports only a partial restoration on 26 May, 87 days after the second shutdown began. For those weeks, any workflow that depended on a model hosted abroad simply stopped. That is why searches for an AI API that works on the national network («نت ملی») are an operational requirement, not a curiosity.

Four routes to a model behind an API

Before comparing brands, compare routes. The question that matters most is where inference physically runs, because that single fact decides data residency, continuity, and legal exposure.

Most organisations end up with a hybrid: a domestic or self-hosted route for anything sensitive or time-critical, and a clearly bounded exception process for anything else. The earlier guide on choosing between Iranian and foreign AI tools covers that tiering from the business side; this article covers the API plumbing.

Domestic AI API providers: read the documentation, not the banner

Searches such as «خرید API هوش مصنوعی» and «api هوش مصنوعی ایرانی» lead quickly to Iranian cloud companies that sell AI access through a single API. ArvanCloud and Liara are two examples that publish documentation for these services. They are presented here in neutral order, from their own documentation, and nothing below is a ranking.

ArvanCloud's AI service documentation describes private API endpoints created per model and protected by keys the customer generates, token usage reports with the related costs, and per-endpoint rate limits set per second or per minute. It states that some models are hosted directly on ArvanCloud's own infrastructure, lists a knowledge-base feature for answering from your own data, and says that fine-tuning and training are not currently available and that conversation history is not stored between API requests.

Liara's AI service documentation describes an AI-as-a-service API whose catalogue spans closed foreign model families (OpenAI, Google Gemini, Anthropic Claude, xAI Grok) alongside open-weight families such as Llama, Mistral, and Qwen. Its overview page does not say where each model is processed or which models, if any, run on servers inside Iran.

That gap is the editorial point. When a domestic provider lists GPT, Claude, or Gemini, the request is being relayed to a foreign model: your prompt leaves the country, the upstream provider's country policy and terms still apply to that traffic, and the route fails when international connectivity fails. An open-weight model hosted on the provider's own servers in Iran is a genuinely different product with different properties. Before any purchase, ask each provider for a written, per-model answer to four questions: where inference runs, what is logged and for how long, which third parties receive the data, and which models remained available during the 2026 shutdowns.

Gateways and routers: what OpenRouter changes, and what it does not

Interest among Iranian developers in OpenRouter and in local routing tools grew visibly during 2026, so it is worth being precise about what these tools are and what they cannot do.

OpenRouter is a unified API in front of hundreds of models from many providers, with an OpenAI-compatible base URL. Its provider-routing documentation explains that, by default, it prefers providers without a recent outage, weights the stable ones toward lower prices, falls back to the next provider when one fails, and offers controls such as zdr to restrict requests to endpoints with a zero-data-retention policy. Those are useful engineering ideas.

Its terms of service, last updated on 31 August 2026, also matter. They are the terms of OpenRouter, Inc., which is based in New York and is therefore itself subject to the US sanctions program described above. They state that certain model providers do not authorise users located in certain countries or regions to access their models, that such "Restricted Models" may not be accessed through the service, and that the service may not be used to resell API access. A gateway does not dissolve upstream restrictions; it inherits all of them and adds its own. For an Iranian company, that is a legal and continuity exposure to assess with counsel, not a workaround.

Local routers are a different category. Tools that Iranian developers search for by name, such as 9router or claude-code-router, run on your own machine as OpenAI-compatible proxies that translate between API formats and fail over between configured upstreams. They change the plumbing, not the rights: every request still needs a legitimate upstream account. Some of these tools advertise rotating several accounts or stacking free tiers to avoid limits, which is precisely the behaviour most provider terms prohibit. A company should not build production workloads on that pattern.

Self-hosting open-weight models with Ollama, vLLM, or llama.cpp

Running an open-weight model yourself is the only route where you control the whole path from prompt to answer. Three mature open-source servers expose an OpenAI-compatible API, which means your application code does not need to change when you move between them or away from them.

• Ollama (اولاما) is the quickest start on a single machine. Its OpenAI compatibility documentation uses the base URL http://localhost:11434/v1/ with an API key that the SDK requires but the server ignores, and supports chat completions, completions, embeddings, model listing, and a non-stateful subset of the Responses API. It documents gaps too, such as no tool_choice and no log probabilities.
• vLLM is built for throughput on GPU servers. Its OpenAI-compatible server documentation starts the server with vllm serve plus a model name and an optional --api-key, and clients connect at http://localhost:8000/v1.
• llama.cpp runs quantised GGUF models efficiently on modest hardware, including CPUs. Its llama-server documentation describes OpenAI-compatible /v1/chat/completions and /v1/completions endpoints on port 8080 by default.

Open weights also include Persian-focused work. Part AI's Dorna2 model card describes an 8-billion-parameter Llama 3.1 derivative adapted for Persian, released under the Llama 3.1 licence, and reports an average of 50.72% on five Persian benchmarks against 50.14% for its base model. That small margin is the developer's own figure, and it is a good reminder that a Persian label is a hypothesis to test, not a result. Operating any open model in production (versioning, patching, evaluation, rollback) is covered in the guide to open-model operations.

Sizing hardware for a self-hosted model

The first-order estimate is simple. Hugging Face's guide to optimising LLMs for speed and memory gives the rule of thumb that loading a model with X billion parameters takes roughly 2 × X GB of accelerator memory in bfloat16 or float16, and 4 × X GB in float32. Its worked example, a 15.5-billion-parameter code model, used about 29 GB in bfloat16, about 15 GB with 8-bit quantisation, and about 9.5 GB with 4-bit quantisation, with a small slowdown and the warning that quantisation can change outputs.

Weights are only the start. The key-value cache grows with context length and concurrent users; in the same guide, that model's cache alone needed around 15 GB at 16,000 tokens before architectural savings such as grouped-query attention. Size for your real prompt length, the number of simultaneous requests, and headroom, then measure on the actual server.

Two local realities belong in the plan. First, the sanctions framework that restricts US-origin exports also covers data-centre hardware, so procurement of accelerators belongs in the same legal review as the software. Second, domestic clouds rent GPU machines, which lets you test a model at production scale before buying anything; if you do, ask the same residency and logging questions you would ask an API provider.

Data residency and privacy for Iranian organisations

"Hosted in Iran" is a starting point, not a control. Classify the data that will enter prompts (customer records, contracts, financial statements, health information), then map every place a request touches: the application server, the gateway, the model server, logs, caches, monitoring tools, and backups. The article on proving AI data residency explains why a region label on a cloud console does not prove where processing happened.

For each route, get written answers on retention, training use, subprocessors, deletion, and access by staff. Decide eligibility before a request reaches a model: sensitive content should never be sent to an ineligible route merely to find out where it belongs. Obligations under sector regulators, contracts, and your internal policy vary by organisation; review them with qualified legal advice rather than inferring them from a vendor's marketing page.

Comparing cost without invented prices

A cheap API («api هوش مصنوعی ارزان») is cheap only if it finishes the task. Compare routes on cost per successful task, built from variables you measure on your own traffic:

• average input and output tokens per task, measured with each provider's tokenizer on your own Persian documents;
• the token price and how it is indexed, especially whether a rial price follows a foreign-currency tariff;
• retry, fallback, and failed-validation rates;
• cache hit rate for repeated questions;
• human review minutes per task and the cost of an error that escapes review.

Persian deserves its own measurement. Research on tokenizer unfairness between languages, presented at NeurIPS 2023, found that the same text translated into different languages can differ in tokenized length by up to 15 times, with direct effects on cost, latency, and how much context fits. Do not assume a multiplier for Persian; count tokens per character on your own corpus.

Self-hosting has a different shape: hardware purchase or rental, power, cooling, the engineer who keeps the stack patched, on-call time, and idle capacity. Divide that fixed monthly cost by the number of successful tasks you actually run. At low volume a per-token API usually wins; at steady high volume, or when continuity has a price of its own, self-hosting can. The only honest comparison is the one computed from your numbers.

Reliability: one interface, tested fallbacks, careful caching

The single most valuable design choice is an internal interface that your application calls instead of any vendor directly. Behind it, keep an ordered list of eligible routes, each with its own base URL, key, model name, timeout, and quality record. When the primary route fails with a timeout, a rate limit, or a server error, the interface moves to the next eligible route and logs which one answered.

Fallback is not free. A smaller local model may be acceptable for classification and unacceptable for a customer-facing answer, so define in advance what the system may still do in degraded mode; the guide to what an AI system may do when its primary model fails sets out that contract. Choosing between routes on cost and quality, rather than only on availability, is the subject of the routing layer. Caching repeated answers reduces both cost and dependence on any one route, but a cached answer can also repeat a mistake or leak across users; the dangerous cache hit explains the guardrails.

Test the whole chain on purpose. Disconnect the primary route in a staging environment, confirm that traffic moves, confirm that sensitive requests do not fall through to an ineligible route, and time how long users wait.

Evaluating Persian quality before you commit

General leaderboards say little about your task. Academic work shows why. A 2025 benchmark of open-source LLMs on Persian tasks found that most models struggle with token-level tasks such as named-entity recognition even when they do well on reasoning. The MELAC evaluation built 19 Persian datasets on subjects such as Iranian law, Persian grammar, idioms, and university entrance exams, and evaluated 41 models, because Western-centred benchmarks miss that knowledge.

Build a small, versioned test set from your own material before choosing a route: formal and conversational Persian, inconsistent use of the zero-width non-joiner (نیم‌فاصله), Arabic and Persian variants of «ی» and «ک», Persian and Latin digits, Solar Hijri dates, mixed Persian and English terminology, and scanned or tabular documents if you process them. Score every candidate route on the same set, including the fallback models, because degraded mode is still production.

A minimal client that swaps providers by configuration

Because every route above can speak the OpenAI-compatible format, the application code can stay the same while the provider changes. The sketch below uses the official openai Python package, reads each route from environment variables, and falls back only on errors that another route could fix.

# pip install openai
import os
from openai import OpenAI, APIConnectionError, APITimeoutError, APIStatusError

# Order is preference. Each route is configuration, not code.
ROUTES = [
    {   # self-hosted vLLM, started with: vllm serve <model> --api-key <key>
        "base_url": os.getenv("PRIMARY_BASE_URL", "http://localhost:8000/v1"),
        "api_key": os.getenv("PRIMARY_API_KEY", ""),
        "model": os.getenv("PRIMARY_MODEL", ""),
    },
    {   # a second OpenAI-compatible endpoint you are contracted to use
        "base_url": os.getenv("SECONDARY_BASE_URL", ""),
        "api_key": os.getenv("SECONDARY_API_KEY", ""),
        "model": os.getenv("SECONDARY_MODEL", ""),
    },
    {   # local Ollama for degraded mode; the SDK needs a key, the server ignores it
        "base_url": "http://localhost:11434/v1/",
        "api_key": "ollama",
        "model": os.getenv("LOCAL_MODEL", ""),
    },
]

RETRYABLE = {408, 429, 500, 502, 503, 504}

def ask(messages, timeout=30):
    failures = []
    for route in ROUTES:
        if not (route["base_url"] and route["model"]):
            continue
        client = OpenAI(base_url=route["base_url"], api_key=route["api_key"] or "unused",
                        timeout=timeout, max_retries=1)
        try:
            reply = client.chat.completions.create(model=route["model"], messages=messages)
            return route["base_url"], reply.choices[0].message.content
        except (APIConnectionError, APITimeoutError) as exc:
            failures.append(f"{route['base_url']}: {type(exc).__name__}")
        except APIStatusError as exc:
            if exc.status_code not in RETRYABLE:
                raise  # a bad request or bad key will not be fixed by another route
            failures.append(f"{route['base_url']}: HTTP {exc.status_code}")
    raise RuntimeError("all routes failed: " + "; ".join(failures))

used, text = ask([{"role": "user", "content": "این بند قرارداد را در دو جمله خلاصه کن: ..."}])
print(used, text)

In production, add the eligibility check from the residency section before the loop, record the answering route with every response, and keep the route list in managed configuration so that switching providers is an operational change rather than a release.

Decision checklist

Use this list before signing anything or writing the first integration:

1. Which workflows must keep working during an international disconnection, and which can pause?
2. For each candidate route, where exactly does inference run, per model, in writing?
3. Do the provider's published terms and country policy permit your use, from your location, for your organisation? If the honest answer depends on an intermediary, drop the route.
4. What is logged, for how long, who can read it, and how is deletion evidenced?
5. How is the price set, in which currency, and how does it change with the exchange rate?
6. What is the measured cost per successful task on your own Persian data, including retries and review?
7. Which fallback route is eligible for each data class, and has failover been tested with the primary disconnected?
8. What quality does each route, including degraded mode, achieve on your versioned Persian test set?
9. Can you export prompts, configuration, evaluation data, and logs if you leave?
10. Who owns the interface, the route list, and the decision to switch?

Disclosure: ZharfAI designs and builds AI systems for organisations and so has a commercial interest in how they are architected. No provider named in this guide paid for inclusion, and the guide recommends none of them. If you want an independent review of your options, including the eligibility rules, fallback design, and Persian evaluation described here, our AI consulting service covers exactly that kind of architecture decision.

Source Notes (reviewed 2026-09-24)

All sources were checked on 24 September 2026. Provider lists, terms, and documentation change without notice; re-check them before you rely on any statement here.

• Provider country policies: OpenAI supported countries and territories; Anthropic supported regions; Gemini API available regions (page updated 28 April 2026). None lists Iran.
• Sanctions framework: OFAC Iran sanctions program. This guide is not legal advice.
• Connectivity: Cloudflare, Q1 2026 Internet disruption summary (28 April 2026) and Cloudflare, Iran's Internet partially restored (27 May 2026).
• Gateways: OpenRouter terms of service (updated 31 August 2026) and OpenRouter provider routing. Described, not endorsed.
• Domestic providers: ArvanCloud AI service documentation and Liara AI service documentation. Vendor statements, not independent verification; no ranking is implied.
• Self-hosting: Ollama OpenAI compatibility, vLLM OpenAI-compatible server, llama.cpp server, and Hugging Face on LLM memory and quantisation.
• Persian quality and cost: Petrov et al., tokenizer unfairness between languages; open-source LLMs benchmarked on Persian; MELAC Persian evaluation; Part AI Dorna2 model card (developer-reported results).