Skip to main content

​
Migrating from Portkey

Portkey and KnoxCall overlap on the gateway itself — one endpoint in front of many providers, with routing, fallbacks and observability — and diverge on where the provider credential lives and what happens to the data passing through. There is no automated importer for Portkey today (its configuration lives in a hosted control plane rather than a file you can hand us), so this is a concept-by-concept mapping you apply by hand. It is usually an afternoon.

​
Concept mapping

​
Before / after

Before — Portkey-style, provider selection in a header or config id:
After — the agent is the config, so the base URL carries it:
Nothing else in your code changes. The routing, the budget, the firewall and the redaction all hang off support-bot, which means they are the same for every caller of that agent rather than dependent on a header any caller can change.

​
Three things that will surprise you

A 429 is returned to you by default. Portkey retries on rate limits out of the box. KnoxCall does not, unless the agent’s routing_policy names "429" in retry_on — because silently absorbing a rate limit into a second provider’s bill is not a decision we make on your behalf. Set it explicitly:
Your app stops holding a provider key entirely. A Portkey virtual key still resolves to a provider credential that the gateway sends onward; the difference here is what your workload holds. A KnoxCall capability token is not a provider credential and cannot be replayed against the provider — it only works against your agent, and only within its scope. Prompt templates have no home here. If you use Portkey’s prompt management, that stays in your application or in whichever tool you prefer. We are a gateway, not a prompt store, and pretending otherwise would leave you with half a feature.

​
What to do about the acquisition

Portkey is now part of Palo Alto Networks (Prisma AIRS). Whether that is good or bad for you depends on whether you wanted a security-platform relationship, and it is not our place to tell you it is bad. The practical question for a migration is continuity of the specific features you rely on and of your commercial terms — worth asking them directly before you plan around either.

​
Suggested order

  1. Create one agent per Portkey config, with its provider and a secret holding that provider key.
  2. Mint one capability token per calling service — not one shared token. Scope each to the models that service actually uses. This is the step that pays for the migration.
  3. Move retry_on / weights across into routing_policy.
  4. Run both gateways in parallel behind a feature flag; compare ai_gateway_usage against your Portkey analytics for a week.
  5. Turn on PII redaction and a firewall policy in warn first, read the events for a few days, then move to block.
Step 5 in warn first is genuine advice, not a hedge. Turning a blocking control straight on in front of production traffic is how a good control gets switched back off after one bad afternoon.