Scattered keys
Provider keys spread across applications and config files, and are hard to withdraw or change when needed.
Gateway deployment
Running them on DIJ Cloud servers or on your servers connected to the platform.
PlannedDIJ AI Gateway
One gateway. for all AI models.
One managed access point between your apps and supported model providers: central keys, usage and cost visibility, and controls you set.
DIJ AI Gateway is currently in early access for companies. We explain the available capabilities and model/provider compatibility before you start.
The problem
Each app connects to a provider on its own.
When each team connects its app straight to the model provider, keys, usage and controls end up scattered in many places.
Limited visibility
Each provider shows its usage its own way, so it's hard to tell who consumed what and at what cost.
Inconsistent controls
Limits, logs and sensitive-data masking apply per application — or not at all.
How it works
From the application to the model. And from the model back to the application.
Every request passes through one point, so the same rules apply to it before it reaches the provider.
- 01
The app sends the request
to a single API endpoint, using a virtual key specific to the app or team.
- 02
The gateway checks
From the key, limits and budget configured for that key.
- 03
Controls before sending
If you enable it, sensitive data can be masked or other controls applied before the request leaves for the provider.
- 04
Routing to the provider
to the configured provider and model, with fallbacks if you set them up.
- 05
Reply and logging
The response returns to the application, and metadata and the estimated cost of the request are logged.
POST /v1/chat/completions
Host: gateway.your-company.example
Authorization: Bearer <virtual-key>
Content-Type: application/json
{
"model": "<configured-model>",
"messages": [
{ "role": "user", "content": "..." }
]
}Capabilities
What you configure in your gateway.
Every capability is labeled with its status. What depends on setup only works once it's configured with you, and what's planned hasn't launched yet.
Depends on setup Works once configuredPlanned Not launched yet
One interface
An OpenAI-compatible API endpoint your applications connect to, instead of connecting to each provider separately.
For supported providersVirtual keys
Provider keys are stored centrally, and each application or team gets its own independent key that can be stopped without touching the rest.
Depends on setupUsage and cost
View usage and estimated cost per key, application or team.
Estimated · depends on setupBudgets and limits
Spend and request-rate limits per key or team, wherever your setup supports them.
Depends on setupRouting and fallbacks
Route requests to the supported providers, and set up fallbacks when needed.
Depends on setupRequest logs
Metadata and cost per request. Logging the text of requests and responses is an explicit option that you decide.
Depends on setupControls and data masking
Configure sensitive-data (PII) masking or other controls before a request reaches the provider. Not enabled automatically.
Not enabled automaticallyDIJ integration
Manage the gateway alongside your servers and applications inside the DIJ-LABS environment itself.
PlannedData handling
What the gateway controls. And what it doesn't.
The gateway alone doesn't guarantee that data stays inside Iraq, and it doesn't prevent data from reaching an external provider. Where processing happens depends on the provider, the model, the deployment method and the logging and control settings.
You control it through the gateway
- Who reaches which model, and from which application.
- What gets logged: metadata only, or the text of requests and responses.
- Request controls before it leaves, such as masking sensitive data.
- Spend and request-rate limits.
Depends on your choices
- The provider and the model, and where they process data.
- How the gateway is deployed and where its servers are.
- The provider's data-retention policies.
- Compliance requirements specific to your company and its regulators.
We review these options with your team before you start. We make no blanket guarantees about privacy, data residency or compliance.
Enterprise fit
For companies adopting AI with care.
For fintechs and large Iraqi institutions that need governance, logs and operational visibility before models spread across teams.
01
Access governance
Who uses which model, from which application, and within what limits.
02Spend visibility
Estimated usage and cost by team and application.
03Review and logs
Logs your security and compliance team can review according to your policies.
04Gradual adoption
Start with one application or one team, then widen the scope as you gain confidence.
DIJ-LABS integration
Alongside your servers and applications.
The goal is for the gateway to be managed inside the DIJ-LABS environment that manages your servers and applications. Anything not yet built we label as planned.
Unified visibility
Show the gateway's status next to server and application health in the DIJ dashboard.
PlannedManaged operations
Monitoring, updates and initial setup within DIJ's managed services.
Planned(FAQ) AI Gateway
Questions before you begin.
It is in early access and available to companies on request. Request a session and we explain what is actually available and what is planned.
The list is set at configuration, by the provider and model you choose. We confirm which providers are actually supported before the trial, and we don't list names we haven't tested.
The gateway uses the OpenAI interface format, so changing the endpoint and key in your app is usually enough. Available interfaces and parameters still depend on the provider and model.
Provider keys are stored in the gateway, and each application or team gets its own independent virtual key. One key can be stopped without affecting the others.
Usage and estimated cost can be shown per key, application or team. The figures are estimates, and their accuracy depends on the provider pricing configured in the gateway.
Yes, wherever your setup supports them: a spend budget and request-rate limits per key or team. We set them up with you during onboarding.
Metadata and the cost of each request can be logged. Logging the text of requests and responses is an explicit option that you decide, set according to your company's policies.
PII masking and other controls can be configured before the request reaches the provider. These controls are set at setup and are not enabled automatically, and on their own they don't guarantee blocking all sensitive data.
Deployment options are discussed based on your company's architecture and requirements. Some are planned and not yet available, and we explain the actual status when you request the trial.
That depends on the provider, the model, where the gateway is deployed and the logging settings. The gateway alone doesn't keep data inside Iraq and doesn't prevent it from reaching an external provider. We review these options with you before you start.
(Start)