Embeddings

One key for the whole retrieval pipeline

A RAG system needs vectors and completions, and most teams end up holding two vendors' keys to get them. Embeddings run through the same gateway as chat here - same credential, same spend caps, same log, same list-price billing with no markup on top.

The same API key, spend caps and request log as your chat traffic - one credential for the whole pipeline
Billed at the provider's list price with no markup, and your own OpenAI key is used if you have connected one
The text is never stored: nothing is generated, so the input goes to the provider and only numbers come back

Indexing and answering run on one credential, one set of caps and one log - instead of two vendors and an addition problem at the end of the month.

The request

curl https://finalrouter.com/api/v1/embeddings \
  -H "Authorization: Bearer $FINAL_ROUTER_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/text-embedding-3-small",
    "input": ["the quick brown fox", "a second string, batched"]
  }'

The response - OpenAI's shape

{
  "object": "list",
  "data": [
    { "object": "embedding", "index": 0, "embedding": [0.013, -0.041, ...] },
    { "object": "embedding", "index": 1, "embedding": [0.007,  0.022, ...] }
  ],
  "model": "openai/text-embedding-3-small",
  "usage": { "prompt_tokens": 12, "total_tokens": 12 }
}

// The same shape OpenAI returns. Existing retrieval code
// does not know it changed hands.

Why put embeddings behind a gateway?

Because retrieval and generation are one system and are usually governed as two. The embedding calls that build your index and the completions that answer from it hit different endpoints, carry different keys, and land in different bills - so “what does this feature cost” becomes an addition problem across vendors.

Through the gateway they are one line of accounting. The same key carries both, the same daily and monthly caps bound both, and the same request log shows both - an embedding request appears exactly like any other, with zero completion tokens.

What the endpoint does

Two models, and every rule that already governs your chat traffic.

Two models, batched

text-embedding-3-small at 1,536 dimensions for volume, text-embedding-3-large at 3,072 when retrieval quality is what matters. Send up to 256 strings in one call.

256 inputs per request · 32,000 characters each

List price, no markup

$0.02 per million tokens for the small model, $0.13 for the large - the provider's own published rate, checked on a recorded date, with nothing added by us.

the same pricing discipline as every chat model

Your key if you have one

Connect an OpenAI key and embeddings run on it, billed by the provider at your rate. The response says which key answered, exactly as chat does.

used_own_key on the request record

Nothing stored, nothing screened

Embeddings generate no text, so there is no output to inspect and no completion to keep. The input passes through and only the vector comes back.

prompt storage does not apply to this endpoint

Through the gateway vs a second vendor

	Final Router	A separate embeddings key
Credentials to hold	One, for vectors and completions	Two, rotated separately
Spend caps	The key's existing daily and monthly ceilings apply	Uncapped, or capped somewhere else
Cost attribution	One log, split by app, session, tag and customer	Two invoices, reconciled by hand
Token price	Provider list price, no markup	Provider list price
Bringing your own key	Supported, and disclosed per request	It is your key by definition

FAQ

Does the free allowance cover embeddings?

No, and the refusal says so plainly. The free allowance is a chat allowance - one model, twenty-five requests a day, an output ceiling - and none of those bounds mean anything for vector workloads. Rather than invent a fourth kind of free, embeddings ask for credit.

Which models can I call?

OpenAI's text-embedding-3-small (1,536 dimensions, the default when you name no model) and text-embedding-3-large (3,072 dimensions). They live in a separate catalogue from the chat models on purpose: chat routing can never pick an embedding model, and an embeddings request can never fall back to a chat model.

Is my text stored or inspected?

Neither. Nothing is generated, so there is nothing to screen and nothing to keep - the text reaches the provider and only numbers come back. Prompt storage, which is opt-in and applies to chat, does not apply here at all.

Do my spend caps apply?

Yes. Embeddings bill against the same balance, count against the same monthly budget, and are bounded by the same per-key daily and session ceilings as your chat traffic. A runaway indexing job is stopped by the limits you already set.

Can I use them for the semantic cache too?

The semantic cache has embedded internally since it shipped - this endpoint makes the same capability available to your own code. They are billed the same way, and the cache's vectors are computed independently of anything you send here.

One key for retrieval and generation

Point your existing embeddings client at the gateway and index against the same credential your completions already use.

Start free - 25 requests a day Read the quickstart