How to Use an LLM Gateway: A Practical Setup Guide

Using an LLM gateway means routing your application's calls to a language model through a single HTTPS endpoint instead of talking to each provider's SDK directly. In practice, this comes down to four steps: get an API key from the gateway, point your existing HTTP or SDK calls at its endpoint, adjust your request payloads to match its format, and use its dashboard or logs to monitor usage and costs.

This guide walks through that process concretely, with working code, so you can go from "I have gateway access" to "my app is calling models through it" in under an hour.

Step 1: Get Your Gateway API Key

Every gateway issues its own API key that sits between your app and the underlying model provider. With SubToAPI, this key looks like sub_live_... and is generated from the dashboard after signup. It replaces whatever key you were using directly with the model provider — you never expose the underlying provider credentials in your application code.

Store it as an environment variable like any other secret:

export SUBTOAPI_KEY="sub_live_xxxxxxxxxxxxxxxx"

Never commit this to source control, and never ship it in client-side JavaScript. Route it through your backend.

Step 2: Make Your First Request

Once you have a key, the basic pattern is a POST request to a messages or completions endpoint with a model name, a list of messages, and a max token limit. Here's a minimal example against SubToAPI:

curl https://api.subtoapi.app/v1/messages \
  -H "Authorization: Bearer $SUBTOAPI_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-sonnet-4",
    "max_tokens": 1024,
    "messages": [
      {"role": "user", "content": "Summarize this changelog in three bullet points."}
    ]
  }'

The response comes back as JSON with the model's reply plus usage metadata (input tokens, output tokens). That usage block is what you'll build cost tracking and rate-limit logic around later, so don't discard it — log it alongside the request. Full request and response shapes are in the messages docs.

If you're starting from zero, the quickstart guide walks through generating a key and sending this exact request in a fresh project.

Step 3: Wire It Into Your Application Code

In a real app you're not shelling out curl commands — you're calling this from a backend service. Here's the same request in Node.js:

async function askModel(prompt) {
  const response = await fetch("https://api.subtoapi.app/v1/messages", {
    method: "POST",
    headers: {
      "Authorization": `Bearer ${process.env.SUBTOAPI_KEY}`,
      "Content-Type": "application/json"
    },
    body: JSON.stringify({
      model: "claude-sonnet-4",
      max_tokens: 1024,
      messages: [{ role: "user", content: prompt }]
    })
  });

  if (!response.ok) {
    throw new Error(`Gateway error: ${response.status}`);
  }

  const data = await response.json();
  return data.content;
}

Wrap this in whatever error handling and retry logic your app already uses for outbound HTTP calls. A gateway doesn't remove the need for timeouts and retries — it just gives you one place to configure them instead of one per provider.

Step 4: Add Streaming for Interactive UIs

If you're building a chat interface or anything where users expect to see tokens appear progressively, switch to streaming mode by setting "stream": true and reading the response as server-sent events instead of waiting for the full JSON body:

const response = await fetch("https://api.subtoapi.app/v1/messages", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.SUBTOAPI_KEY}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    model: "claude-sonnet-4",
    max_tokens: 1024,
    stream: true,
    messages: [{ role: "user", content: "Write a haiku about deploys." }]
  })
});

const reader = response.body.getReader();
const decoder = new TextDecoder();

while (true) {
  const { done, value } = await reader.read();
  if (done) break;
  process.stdout.write(decoder.decode(value));
}

Details on event types and parsing chunks are in the streaming docs.

Step 5: Use Tool Calls If Your App Needs Them

If your application needs the model to call functions — looking up a database record, hitting an internal API, running a calculation — define tools in your request and handle the tool-use response the gateway sends back. The model doesn't execute anything itself; it tells you what it wants to call and with what arguments, and your code runs it and sends the result back in a follow-up message. This pattern is the same whether you're building a support bot or a coding agent. See the tools docs for the full request/response cycle.

Step 6: Monitor Usage and Manage Access

Once requests are flowing, the operational side of "using" a gateway is watching what it costs and who's calling it. A good gateway dashboard should show you:

• Token usage broken down by day, by application key, or by team member
• Which models are being called and how often
• Error rates, so you catch a broken integration before it burns through quota

SubToAPI's dashboard covers all three, and if you're running a team, you can issue separate keys per developer or per environment (staging vs production) rather than sharing one key across everyone. This matters more than it sounds — separate keys mean you can revoke one leaked credential without rotating everything, and you can see exactly which part of your system is driving spend. Plans scale from Solo (€9) for individual use up to Team and Scale tiers with per-seat pricing for larger groups — see pricing for the current breakdown.

Common Mistakes When Getting Started

• Hardcoding the API key in client code. Always proxy through your own backend.
• Ignoring max_tokens. Leaving it unset or too high on every request is the fastest way to an unexpectedly large bill.
• Not checking the usage field in responses. It's there specifically so you can track cost per request without guessing.
• Skipping streaming for chat UIs. Users notice the difference between instant partial output and a multi-second blank screen.

Questions

Do I need to change my model prompts to use a gateway? No. The gateway sits at the transport layer — you send the same messages and prompts, just to a different endpoint with a different API key. Model behavior doesn't change because a gateway is in front of it.

Can I use a gateway with an existing app that already calls a model provider directly? Yes. Swap the base URL and API key, keep your existing request structure if it's already Claude-compatible, and test on a staging key before rolling out to production traffic.

Is a gateway only useful for teams, or does it help solo developers too? It helps both. Solo developers get one clean key with usage tracking instead of juggling provider consoles; teams add per-seat keys, shared billing, and centralized monitoring on top of that same foundation.