Requesty10 min readUpdated 2026-04-09

Migrating from Requesty to Phaseo Gateway

Migrate from Requesty to Phaseo Gateway with an OpenAI-compatible approach: endpoint/key swap, model compatibility checks, and production validation.

Try Phaseo

Prerequisites

Your current Requesty client configuration and env vars.
`PHASEO_API_KEY` available in all deployment environments.
A baseline of current latency/error metrics for comparison.

1) Capture baseline behavior

Before changing config, capture representative prompt outputs, latency, and error behavior from your current Requesty setup.

This baseline gives you objective pass/fail criteria after migration.

Checklist

Save responses for a small golden prompt set.
Record median latency and error rate.
Document current fallback model behavior.

2) Replace endpoint and credentials

Treat this as an OpenAI-compatible migration. Keep payload shape first and only update endpoint + API key source.

Move old Requesty key names to `PHASEO_API_KEY` to standardize runtime config.

Before (Requesty-Style OpenAI-Compatible Client)

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.REQUESTY_API_KEY,
  baseURL: "https://router.requesty.ai/v1",
});

After (Phaseo Gateway)

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.PHASEO_API_KEY,
  baseURL: "https://api.phaseo.app/v1",
});

3) Verify model availability and normalize IDs

Check that your existing model IDs are valid in Phaseo. If needed, centralize mapping in one resolver function.

Avoid ad-hoc replacements throughout the codebase; keep migration edits reversible.

Model Availability Check

curl -s "https://api.phaseo.app/v1/models" \
  -H "Authorization: Bearer $PHASEO_API_KEY" | jq '.data | length'

Single-Boundary Model Resolver

export function resolveGatewayModelId(input: string): string {
  const aliases: Record<string, string> = {
    "gpt-4.1-mini": "openai/gpt-4.1-mini",
  };
  return aliases[input] ?? input;
}

4) Run migration validation and promote

Run your golden prompt set and compare output quality, latency, and costs against the baseline.

Promote traffic gradually and keep old config available until stability is confirmed.

Checklist

Pass non-streaming and streaming tests.
Compare against baseline metrics from step 1.
Promote gradually and observe for at least one release cycle.

Validation steps

curl -s "https://api.phaseo.app/v1/health"
curl -s "https://api.phaseo.app/v1/models" -H "Authorization: Bearer $PHASEO_API_KEY"
Replay your golden prompt set through the migrated path.
Verify one invalid-key error path and one invalid-model error path.

Frequently asked questions

Can I migrate without changing business logic?

Usually yes. Keep changes at the gateway client boundary (endpoint, key, and optional model mapping) and leave calling code intact.

Does Requesty require provider-prefixed model IDs?

Yes for their OpenAI-compatible routing examples (for example `openai/gpt-4o`). Verify your production IDs before cutover.

Should I keep old Requesty env vars during rollout?

Yes during canary, but plan to remove them after full cutover to prevent config drift.

Need a custom migration diff?

Use the interactive assistant for before/after snippets tailored to your current SDK and language.

Open Migration Assistant

1) Capture baseline behavior

Before changing config, capture representative prompt outputs, latency, and error behavior from your current Requesty setup.

This baseline gives you objective pass/fail criteria after migration.

Checklist

Save responses for a small golden prompt set.
Record median latency and error rate.
Document current fallback model behavior.

2) Replace endpoint and credentials

Treat this as an OpenAI-compatible migration. Keep payload shape first and only update endpoint + API key source.

Move old Requesty key names to `PHASEO_API_KEY` to standardize runtime config.

Before (Requesty-Style OpenAI-Compatible Client)

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.REQUESTY_API_KEY,
  baseURL: "https://router.requesty.ai/v1",
});

After (Phaseo Gateway)

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.PHASEO_API_KEY,
  baseURL: "https://api.phaseo.app/v1",
});

3) Verify model availability and normalize IDs

Check that your existing model IDs are valid in Phaseo. If needed, centralize mapping in one resolver function.

Avoid ad-hoc replacements throughout the codebase; keep migration edits reversible.

Model Availability Check

curl -s "https://api.phaseo.app/v1/models" \
  -H "Authorization: Bearer $PHASEO_API_KEY" | jq '.data | length'

Single-Boundary Model Resolver

export function resolveGatewayModelId(input: string): string {
  const aliases: Record<string, string> = {
    "gpt-4.1-mini": "openai/gpt-4.1-mini",
  };
  return aliases[input] ?? input;
}

4) Run migration validation and promote

Run your golden prompt set and compare output quality, latency, and costs against the baseline.

Promote traffic gradually and keep old config available until stability is confirmed.

Checklist

Pass non-streaming and streaming tests.
Compare against baseline metrics from step 1.
Promote gradually and observe for at least one release cycle.

Frequently asked questions

Can I migrate without changing business logic?

Usually yes. Keep changes at the gateway client boundary (endpoint, key, and optional model mapping) and leave calling code intact.

Does Requesty require provider-prefixed model IDs?

Yes for their OpenAI-compatible routing examples (for example `openai/gpt-4o`). Verify your production IDs before cutover.

Should I keep old Requesty env vars during rollout?

Yes during canary, but plan to remove them after full cutover to prevent config drift.