BYOK: bring your own AI API keys to your PIM

BYOK — Bring Your Own Key. Behind this acronym lies an architectural choice that fundamentally changes the relationship between your PIM and AI costs. Here’s why bringing your own API keys is often the best decision, and when managed credits make sense.

The traditional model: credits sold by the provider

Many SaaS tools that incorporate AI operate on a proprietary credit model: you purchase a pack of “AI credits” from the publisher; each data enrichment consumes a certain number; and when you run out, you top up.

This model has several drawbacks for resellers handling large volumes:

• Opaque costs— you don’t know exactly which underlying API call corresponds to which credit
• Publisher’s margin— credits are systematically more expensive than direct API calls; the publisher takes its cut
• Vendor lock-in— you are tied to the AI provider chosen by the publisher, with no option to switch if a competitor becomes cheaper or more efficient
• Privacy— your product data passes through the publisher’s infrastructure before reaching the LLM

The BYOK model: your keys, your bill, your choice

With the BYOK model, you create your own account with OpenAI (or Anthropic, or Gemini, or Mistral…), obtain an API key, and configure it in your PIM. AI calls are billed directly to your account, at each provider’s public rates.

Benefits:

• Total transparency— you can see exactly how much each enhancement costs, in your OpenAI/Anthropic dashboard
• Optimal cost— you pay the published rate, with no publisher mark-up. For large volumes, the difference is significant
• Freedom of choice— you can switch models at any time, or use different models depending on the task (a fast, cheaper model for simple enhancements, a premium model for complex records)
• Controlled privacy— you control which data goes to which provider, and you can configure Ollama for 100% local processing

Cost comparison: a practical example

To enrich 10,000 product records (generating a description + title + 5 attributes):

*Estimates based on average volumes. Actual costs depend on the length of the files and the configured prompts.

Where the AI bill actually comes from

The table above gives orders of magnitude, but it hides what makes the bill vary by a factor of five from one catalogue to the next. An LLM call is billed per token, on input and on output, at different rates. Three variables therefore drive the real cost — and none of the three is the number of products:

• The length of the context you send — a prompt carrying the full supplier datasheet, three technical documents and twenty examples costs several times one that only sends the attributes that matter. This is the first lever, by far.
• The number of calls per record — an enriched record rarely takes a single call: a description, a title, attributes, an alt tag per image. Multiply by the number of languages if you translate.
• Retries — a response that fails validation is replayed. A poorly framed prompt is paid for twice.

The credit model hides those three variables behind a single counter: you watch a balance melt without knowing whether the cause is the prompt, the model or the volume. BYOK exposes them in the provider’s dashboard, line by line — uncomfortable in the first week, profitable afterwards.

The best AI call is the one you never make

Bringing your own keys isn’t enough: you also have to avoid burning them. That is the whole point of the Pixee PIM enrichment pipeline, organised in two phases — collect, then synthesize.

The collect phase queries your indexed document base first: supplier datasheets, manuals and certificates, vectorised in a local Qdrant. If document coverage is sufficient — at least three relevant passages — no web search is triggered, and collection costs nothing. Otherwise the pipeline automatically falls back to a configurable web search, which you can self-host.

The synthesize phase then hands everything to an LLM of your choice, with an explicit priority rule: document sources always take precedence over the web. You get a record whose every element has a known origin, and you pay the LLM only once, on an already filtered context.

The practical, counter-intuitive consequence: indexing your supplier PDFs before launching an enrichment batch does more for the bill than switching models.

Provider Assignments: the right model for every task

Pixee PIM allows you to configure a different provider depending on the usage context:

• Batch enrichment— GPT-4o mini or Mistral Small (fast, cost-effective)
• AI Copilot— GPT-4o or Claude (complex reasoning), the most demanding context; we cover how it works in querying your catalogue in natural language
• Translation— DeepL (superior quality to general-purpose LLMs for translation); the BYOK setup for DeepL is covered in translating your catalogue with DeepL in BYOK mode
• Vision / AI Tagging— GPT-4o or Claude (multimodal models)
• Compliance extraction— Claude or GPT-4o (analysis of long documents)
• Self-hosted confidential— Ollama with Llama 3 or Mistral (sensitive data, no cloud)

This granularity allows us to optimise the cost-quality ratio for each use case, rather than using the same (often the most expensive) model for everything.

Router, cache and cost estimation before execution

Three mechanisms complete this per-context assignment:

• A response cache — two identical requests do not trigger two billed calls.
• A cost estimate before execution — you see what the batch will cost before launching it, not after.
• An automatic fallback — on a provider error or a rate limit, the router switches to the fallback provider instead of interrupting the run.

That last point is the honest flip side of BYOK: with your keys, your account’s rate limits become yours to manage. A batch of several thousand records launched on a recent provider account, still on a low usage tier, will get throttled. Configuring a second provider as a fallback is not a luxury — it costs nothing as long as it is not used.

Governing your keys: what BYOK hands you

A credits model offloads a share of administration onto the vendor. With BYOK, it comes back to you. It is light, but it exists, and it is worth framing from the very first key:

• One key per environment — production, staging, test machine. Revoking the staging key must never stop production.
• A spend cap on the provider side — the main providers offer budget limits and alerts. That is the real safeguard: it applies even if a job loops, which no setting on the PIM side can guarantee.
• A planned rotation — an API key is a secret like any other. It gets replaced, and the operation must be doable without downtime: add the new one, reassign the contexts, remove the old one.
• An identified owner — the key belongs to the company, not to the product manager who opened the account with a personal address. It is the most common mistake, and it surfaces the day that person leaves.

When a managed-credits model makes sense

The BYOK model isn’t always the right choice. A managed-credits model — offered by most competing PIMs — can be preferable if:

• You do not wish to manage an account with an AI provider (billing, rate limits, monitoring)
• Your volume is low and the operational simplification is worth the marginal extra cost
• You are in a testing phase and do not wish to commit to a provider before validating the results

Pixee PIM has chosen 100% BYOK: no AI credits resold with a markup. If a credits model suits you better, it’s a criterion to compare among the vendors that offer it — keeping in mind the extra cost, often 2 to 10× the direct provider price.

How to set up your first BYOK key

1. Create an account on platform.openai.com (or your preferred provider)
2. Generate an API key in your account settings
3. In Pixee PIM, go to AI Services → Providers → Add a provider
4. Select OpenAI, paste your key, and test the connection
5. In Provider Assignments, assign this provider to the desired contexts (enrichment, copilot…)

Setup takes less than 5 minutes and you can run your first enrichment batch immediately.

Frequently asked questions

What happens if my key hits its rate limit mid-batch?

The router switches to the fallback provider assigned to that context instead of interrupting the run. This is why it is worth configuring at least two providers from the start, even if you only use one day to day. Failing that, the only remedy is to split batches and spread them out — which means paying in time what you chose not to pay in configuration.

Do you need one key per use case, or one key per provider?

One key per provider is enough: it is the per-context assignment that decides which provider handles what, not the key. Do separate environments, though. A test key that ends up in a Git repository must never be the one feeding production, and the day it has to be revoked in a hurry, the question should not even arise.

Is BYOK available from the first paid plan?

Yes — BYOK AI enrichment is part of the paid plans from the first tier, and the 30-day free trial includes it too, alongside the catalogue and imports and within a 2,000-product limit — enough to get your data structure right before plugging an LLM into a full catalogue, which is the right order anyway. Per-plan details are on the pricing page.

Can a catalogue be enriched without any data leaving your infrastructure?

Yes, provided you choose local components end to end: Ollama as the LLM provider, the Qdrant document base hosted on your side, and a self-hosted web search — or none at all, if your supplier documentation is enough. Your data then never leaves your infrastructure. The trade-off is hardware, and writing quality stays behind the most recent proprietary models; for extracting technical attributes from documents, the gap is often acceptable.