01
Create an account and mint an API key
You should be able to: Create a Gatewayz account, choose the right key environment, and store the key safely.
Start at the Gatewayz developer docs (https://beta.gatewayz.ai/docs) and create an account. In settings you issue an API key, which starts gw_ and is the credential every request carries to identify and bill you. Copy it once; a key is shown in full only at creation.
Choose the key environment deliberately, because it decides what you can do without paying. A test (or development) key is free and rate-limited — enough to evaluate the whole API without a card. A live (or staging) key requires a payment signal on the account: credits are bought through Stripe checkout with a $5 minimum and are granted as soon as the payment settles. Gatewayz gates live keys behind credits on purpose — free keys are farmable, and requiring a card is the cheapest filter a bot cannot manufacture. Ask for a live key with no credits and the API answers 402, naming the free alternative.
Treat the key as a secret from the first second. It is exactly as sensitive as a password: anyone holding it can spend against your account. Put it in an environment variable or a secret manager, never in source code, never in a commit, never in a screenshot. This is not estate paranoia — it is the single most common way people leak paid credentials.
A practical habit: one key per environment, so you can revoke a leaked or retired key without taking down everything else. If a key is ever exposed, rotate it — generate a new one and delete the old — because deleting the file it was in does not un-leak it. The key is the whole of your identity to the gateway; everything else in this course assumes it is set and safe.
Source: Gatewayz — developer documentation
02
The unified endpoint, and why it is OpenAI-compatible
You should be able to: Explain what the unified endpoint is and why OpenAI-compatibility makes adoption almost free.
Gatewayz exposes one base URL — https://api.gatewayz.ai/v1 — that all your requests go to, regardless of which underlying provider serves them. That is the "unified" in unified gateway: you integrate once and reach every model in the catalog through it. The primary endpoint is POST /v1/chat/completions, the OpenAI-compatible surface most tools already speak.
It is genuinely two-API, not one wearing a costume. Alongside the OpenAI-compatible /v1/chat/completions, Gatewayz serves POST /v1/messages — the Anthropic Messages API, natively rather than through a translation proxy — so a client built for Anthropic (Claude Code, for one) points at the same host and works directly. There is also POST /v1/embeddings and GET /v1/models, the catalog. Because both chat surfaces are the de-facto standards, adopting Gatewayz is usually two changes to code you already have: point the base URL at Gatewayz, and use your Gatewayz key.
This compatibility is a deliberate and load-bearing design choice. It lets a gateway be adopted without a migration — the whole ecosystem of OpenAI- and Anthropic-compatible clients works unchanged. It is also what makes leaving cheap, which is the honest signal of a layer that expects to earn its place rather than trap you.
03
Your first completion
You should be able to: Make a working chat completion through Gatewayz from the command line and from code.
With your gw_ key in an environment variable, a first call is a standard OpenAI-compatible chat completion against the real base URL. From the shell:
curl https://api.gatewayz.ai/v1/chat/completions \
-H "Authorization: Bearer $GATEWAYZ_API_KEY" \
-H "Content-Type: application/json" \
-d '{"model": "anthropic/claude-sonnet-4-5-20250929", "messages": [{"role": "user", "content": "Say hello in one sentence."}]}'
In code, use any OpenAI-compatible SDK and change exactly two lines. With the OpenAI Python client: OpenAI(base_url="https://api.gatewayz.ai/v1", api_key=os.environ["GATEWAYZ_API_KEY"]), then client.chat.completions.create(model="anthropic/claude-sonnet-4-5-20250929", messages=[...]) exactly as you would normally. The response carries the generated message and a usage block with input and output token counts — the same levers from the inference course, itemised on every call.
Source: What Inference Is
04
Choosing a model from the catalog
You should be able to: Find a model in the catalog and pick one deliberately using the four axes.
The catalog is the point of a gateway: a large set of models across the major commercial providers and open-source networks, reachable through the one endpoint you already integrated. Each is addressed by a namespaced model id of the form provider/model — anthropic/claude-sonnet-4-5-20250929, anthropic/claude-opus-4-5-20251101, openai/gpt-4o, openai/gpt-4o-mini — which is the string you put in the "model" field. GET /v1/models returns the catalog in OpenAI list shape.
Read the catalog before you assume a feature. Each entry carries supported_parameters and a capabilities object, so a client can check whether a model supports tools, vision or prompt caching before sending a request — capabilities.prompt_caching is the field to check before you count on a cache. This is how you avoid the silent trap where an unsupported feature is quietly ignored rather than refused.
Choose the way the choosing-inference course taught: not "which is best" but "which clears this task's bar most cheaply". Start a high-volume task on a small inexpensive model and move up only if it fails the bar; start a hard reasoning task on a capable model and move down only if a cheaper one passes. Because switching is a one-word change to the model id, you commit to nothing by picking one now — treat the id as a dial you will tune, which is exactly the posture the build course turns into automatic routing.
Source: Why Choosing Inference Matters
05
Credits, usage, and reading your spend
You should be able to: Fund an account, find usage, and reconcile spend against the token counts in responses.
Gatewayz runs on credits: you fund a balance through Stripe checkout (a $5 minimum, granted as soon as the payment settles), and each call draws it down by the tokens it used at the chosen model's rate. A live key with no credits, or an exhausted balance, is the 402 from the last lesson — the body names the free test-key alternative. A test key stays free and rate-limited, so you can evaluate before you ever top up.
Read spend from two places. The dashboard shows your balance and a usage view; the per-call usage block in every response shows the tokens for that specific call — and it is richer than input/output: prompt_tokens, completion_tokens, and, when caching is in play, cache_read_input_tokens and cache_creation_input_tokens. Reconcile them once so you trust the numbers: make a few calls, note the counts, and check the usage view moves the way you expect.
A note the estate learned the hard way and this course inherits: a provider's aggregate usage feed cannot attribute a figure to one specific request, so treat the dashboard total as reconciliation and the per-call token counts as your source of truth for what any given call cost. With an account, a key, a working call, a chosen model and visible spend, you are set up — and ready to build.
Source: Building with Gatewayz
