Key facts
| Azure endpoint | https://<resource>.openai.azure.com with an api-version query parameter and api-key header |
| Plugsky endpoint | https://api.plugsky.com/v1/chat/completions with Authorization: Bearer sk-live-… |
| Model addressing | Azure deployment names become Plugsky model ids from a catalogue of 30+ models |
| Client change | Swap AzureOpenAI for OpenAI; the chat.completions call shape stays the same |
| Auth options | Bearer API keys; VPC, on-prem and air-gapped deployments for stricter boundaries |
| Streaming and tools | Streaming, function calling and JSON mode are live |
| Regions | Pin me-central-1 (UAE), eu-west-1, us-east-1 or ap-southeast-1 |
| Roadmap | The responses endpoint and batch API are coming soon; plan around /v1/chat/completions today |
TL;DR
- Delete the api-version parameter and the per-resource endpoint.
- Replace deployment names with real model ids.
- One global base URL replaces per-resource Azure hosts.
- The chat.completions request and response shapes are unchanged.
- Entra ID managed-identity patterns need a bearer key or a private deployment.
How it works, step by step
- Inventory Azure deployments and map each to a Plugsky model id.
- Create a Plugsky API key and store it as PLUGSKY_API_KEY.
- Swap AzureOpenAI for OpenAI and change azure_endpoint to base_url https://api.plugsky.com/v1.
- Remove api_version from the client and deployment names from requests.
- Re-test content-filtering assumptions against Plugsky's PII handling modes.
- Run streaming, tools and JSON-mode integration tests on the new endpoint.
- Roll out per workload and keep the Azure client available for rollback.
Original data
Try it yourself
Open the OpenAI migration checker →
What actually changes
Azure OpenAI is an OpenAI-compatible API behind an Azure-shaped wrapper. Three wrapper features disappear when you move to Plugsky:
- Per-resource endpoints: Azure uses
https://my-resource.openai.azure.com. Plugsky uses one global base URL,https://api.plugsky.com/v1. - api-version: Azure requires a version query parameter that changes with features. Plugsky has no version parameter.
- Deployment names: Azure addresses a deployment you created, not the model id. Plugsky addresses models directly, for example
plugsky-pro.
Everything else — messages, temperature, streaming, tools, JSON mode — is the same schema, because both are built on the OpenAI chat completions contract.
Migrating the code
The original Azure client:
from openai import AzureOpenAI
client = AzureOpenAI(
azure_endpoint="https://my-resource.openai.azure.com",
api_key="azure-key",
api_version="2024-10-21",
)
resp = client.chat.completions.create(
model="gpt-4o-deployment",
messages=[{"role": "user", "content": "Summarise this ticket."}],
)The Plugsky client:
from openai import OpenAI
client = OpenAI(
api_key="sk-live-…",
base_url="https://api.plugsky.com/v1",
)
resp = client.chat.completions.create(
model="plugsky-pro",
messages=[{"role": "user", "content": "Summarise this ticket."}],
)Keep the call site and the response handling; only the constructor and the model string change. If you use the Azure async client, the same swap applies to AsyncAzureOpenAI and AsyncOpenAI.
Auth, networking and content filters
Teams that authenticate with Entra ID managed identities should plan this step explicitly. Plugsky authenticates with bearer API keys, and regulated teams that need stronger isolation can deploy in a VPC, on-prem or air-gapped environment under their own network controls. Decide per environment:
- Cloud API: bearer key in a secret manager, rotated quarterly.
- VPC deployment: Plugsky runs inside your cloud account and network boundary.
- On-prem or air-gapped: for workloads that cannot leave your data centre at all.
Content filtering also changes. Azure applies its own filters by default; Plugsky offers no-PII, detect-only and passthrough modes for handling sensitive data, with detect-only the default for inference and no-PII for embeddings. Validate redaction behaviour against your compliance requirements before cutover.
Validation checklist
Before moving production traffic:
- Model parity: diff outputs on a representative prompt set for every deployment you map.
- Streaming: confirm SSE chunks arrive and your client renders them; Azure event formats are close but not identical in SDK versions.
- Tools: run each function-calling flow end to end, including parallel tool calls if you rely on them.
- JSON mode: re-validate every structured output parser.
- Errors: update retry logic for the OpenAI error schema and 429
Retry-Afterhandling. - Observability: add request ids from Plugsky to your logs so support can correlate issues.
The responses API and batch endpoint are coming soon on Plugsky, so any Azure workload built on those APIs should stay on Azure or be refactored to chat completions for now.
Honest comparison
| Capability | Plugsky | Azure OpenAI | Dual-run gateway |
|---|---|---|---|
| Endpoint style | One global base URL | Per-resource endpoint plus api-version | Route by environment prefix |
| Auth | Bearer sk-live-… | api-key header or Entra ID | Both credential types |
| Model addressing | Model ids directly | Deployment names you create | Maintain a name map |
| Residency | Region pin plus VPC, on-prem and air-gapped options | Azure regions and data zones | Policy per route |
| Unique extras | Flat plans, fusion model, model choice | Content filters, provisioned throughput | Keep Azure extras where needed |
| Migration effort | Swap client class and base URL, map model names | Incumbent | Ongoing gateway maintenance |
Frequently asked questions
Can I still use the OpenAI SDK?
Yes. Switch from AzureOpenAI to OpenAI and set base_url to https://api.plugsky.com/v1. The chat.completions call shape does not change.
What happens to deployment names?
They are replaced by real model ids. Map each Azure deployment to a Plugsky model such as plugsky-pro, plugsky-lite or plugsky-embed.
Do I need an api-version parameter?
No. Plugsky does not use versioned query parameters on the chat completions endpoint.
How does authentication change with managed identity?
Entra ID tokens are replaced by bearer API keys. Teams needing stronger isolation can use VPC, on-prem or air-gapped deployments.
What about Azure content filters?
Plugsky uses PII handling modes instead — no-PII, detect-only and passthrough. Validate the mode against your compliance policy.
Are streaming and tools supported?
Yes. Streaming, function calling and JSON mode are live on the chat completions endpoint.
Can I migrate only part of my traffic?
Yes. Keep both clients behind a feature flag or gateway and shift workloads one at a time while comparing evals.
What should I do about the Responses API?
It is coming soon on Plugsky. Until then, refactor Responses API workloads to /v1/chat/completions or keep them on Azure.