Enterprise Quickstart

OpenDunes is designed for teams that need multiple isolated API keys, spend controls, and a compliance posture that satisfies Algerian data-protection law (Law 18-07). This page walks through the full setup from first deposit to production-ready keys.

Account setup#

1. Create an organization account at opendunes.com.
2. Deposit DA with a CIB or Edahabia card from Dashboard → Billing. DA is the only billing currency — every invoice and balance is in dinars.
3. Verify your email. Your default API key is created automatically and visible in Dashboard → Keys.

Create team keys#

Isolate workloads by creating one key per service, environment, or team member. That way a compromised key can be rotated without disrupting everything else.

Each key:

• Looks like sk- followed by a hex string. It's shown only once — copy it before closing the dialog.
• Has its own usage counters, optional spending cap in DA, and model allow-list.
• Can be revoked without touching other keys.

Create keys from Dashboard → Keys, or provision them programmatically with the Management API. Management calls use a separate mk-… management key — created in Dashboard → Settings → Management Keys — never a regular sk- key:

curl https://opendunes.com/v1/keys \
  -H "Authorization: Bearer $OPENDUNES_MANAGEMENT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"name": "production-backend", "limit": 5000, "limit_reset": "monthly"}'

A 201 response returns the key record under data plus key — the sk-… value is shown once, so store it immediately:

{
  "data": { "hash": "9f86d081…", "name": "production-backend", "limit": 5000, "limit_reset": "monthly" },
  "key": "sk-…"
}

A key is named by its hash, the SHA-256 of the key. List existing keys with GET /v1/keys (returns {"data": [...]}), change one with PATCH /v1/keys/{hash} (its name, cap, or disabled) and delete one with DELETE /v1/keys/{hash}. To rotate a key, create the replacement, move traffic over, then delete the old one. Model allow-lists are set per key from Dashboard → Keys.

Set per-key limits#

A spending cap in DA prevents any single key from draining the shared balance. When a key has spent its cap, its requests return 402 with error.metadata.limit_source key — other keys keep working. Spend itself is drawn from the shared account balance: when the balance reaches zero, requests return 402 with limit_source wallet.

You can update a key's cap and model allow-list at any time from Dashboard → Keys via Edit Limits.

Monitor usage and analytics#

Every request is logged with model, token counts, DA cost, and a UUID-v7 trace ID (X-Request-Id response header). View the breakdown by key, model, and time range in Dashboard → Analytics.

Programmatic access is live: GET /v1/activity returns daily usage rollups and GET /v1/credits returns your balance — both authenticated with your management key (mk-…); an sk- key there answers 401. The X-Balance-Available header on every response also gives you real-time balance visibility in micro-DA:

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://opendunes.com/v1",
    api_key=os.environ["OPENDUNES_API_KEY"],
)

resp = client.chat.completions.create(
    model="openai/gpt-5.4",
    messages=[{"role": "user", "content": "Summarize the latest quarter."}],
)

# Read remaining balance from the raw HTTP response
# (OpenAI SDK exposes this via resp._response.headers on most versions)
print(resp.choices[0].message.content)

Law 18-07 compliance#

Algeria's Law 18-07 on personal data protection applies to any system that processes user PII. OpenDunes addresses this at the infrastructure level so you don't have to build your own redaction pipeline.

What OpenDunes does for you:

• PII redaction — prompt and response content is scanned before storage; detected PII (names, phone numbers, national IDs, email addresses) is replaced with type tokens (e.g. [NAME]) in logs.
• Data residency — request logs are stored on infrastructure physically located in Algeria.
• Audit trail — every request carries a UUID-v7 trace ID, logged with timestamp, model, and key identifier (never the key itself). Audit exports are available on request.
• Append-only ledger — all billing movements are double-entry and immutable. No record is deleted or modified after creation.

Note. Your application is still responsible for what you send in messages. Do not send raw user-submitted PII (e.g., full national ID scans, medical records) in prompt text unless your use case specifically requires it and you have documented consent under Law 18-07.

Rate limits#

There is no cap on the number of requests, for any account. A 429 comes from the provider serving the model when it is limiting its rate:

{
  "error": {
    "code": 429,
    "message": "Rate limit exceeded.",
    "metadata": {
      "error_type": "rate_limit_exceeded"
    }
  }
}

Honor the Retry-After header and implement exponential backoff for production systems.

Recommended team key structure#

Rotate keys on a schedule (quarterly is a common baseline) and immediately on any suspected leak.

Next steps#

• API Keys reference — full key lifecycle documentation.
• Limits — spending limits, headers, and retry strategy.
• Models — browse the full catalog with DA pricing.
• Build a Chat App — end-to-end chat example.