Key facts
| SaaS fit | Customer OAuth in your app; one scoped key per tenant environment |
| API auth | Bearer API keys, scoped per environment and revocable on rotation |
| Workforce identity | SSO with SCIM provisioning for your own team |
| Authorization | RBAC plus per-tenant entitlements in your gateway |
| Streaming | Server-sent events for user-facing output; function calling works with streaming |
| Audit | Key lifecycle and admin events exportable to SIEM, usage per key |
| Pricing | Flat monthly self-serve plans; no per-token billing |
| Free plan | plugsky-micro and plugsky-lite, no card; 14-day full-access trial |
TL;DR
- Run customer OAuth in your product; run model access through server-side scoped keys.
- Store customer tokens in your vault and map plan entitlements to a key or quota bucket.
- Never expose the Plugsky key to a browser, mobile binary or third-party script.
- Rotate per-tenant keys, and revoke them the moment a subscription lapses.
- Log usage per tenant so billing, limits and support all read from one source.
How it works, step by step
- Decide which customer action needs delegated access — connecting a mailbox, CRM or drive — and register your OAuth client accordingly.
- Implement authorization code with PKCE, exchange codes server-side, and store refresh tokens encrypted in your vault.
- Create one scoped Plugsky key per environment, and allocate per-tenant key sets or quota buckets according to plan entitlements.
- Broker every model call in your backend: validate the session, check the entitlement, then attach the scoped key and call the OpenAI-compatible endpoint.
- Stream responses over server-sent events for interactive features, and use JSON mode or function calling for structured jobs.
- Log tenant, user, model, tokens and latency on every call, and surface usage in your admin console.
- Automate rotation and revocation so subscription changes, churn and security events all cut access immediately.
Try it yourself
Open the OpenAI-compatible API tester →
Two flows, clearly separated
The first flow is your customer connecting an external account: mailbox, CRM, storage, calendar. That is classic OAuth 2.0 — authorization code with PKCE, refresh tokens in your vault, scopes tied to the integration's purpose. The second flow is model access: your service calling Plugsky. That uses scoped API keys held server-side, never a customer token and never a key shipped to the client.
Keeping the two separate means revocation is clean. A customer disconnecting an integration does not touch your model keys, and rotating a model key does not force customers through a re-consent screen.
Implementation notes that prevent incidents
Put a broker between your product and the model API. It validates the session, resolves the tenant's plan and entitlement, picks the correct scoped key from your secrets manager, and forwards the request. That is the only place that needs to know which key maps to which tenant.
- Entitlements: plan tier decides model access, quota and feature flags.
- Isolation: namespaced retrieval and per-tenant logging prevent cross-account leakage.
- Rotation: two-key windows for zero-downtime rotation, revocation on churn.
- Observability: usage per key feeds billing, abuse detection and support.
Scale, cost and roadmap honesty
Interactive features should stream; long jobs should queue and reconcile asynchronously. Route routine classification and summarisation to plugsky-micro or plugsky-lite, and reserve larger models for reasoning, all behind one OpenAI-compatible endpoint with 30+ models. Flat monthly self-serve plans keep gross margin stable as tenant usage grows; see the live pricing page for tiers.
Be precise in your own roadmap about endpoint status: chat, streaming, JSON mode, function calling and embeddings are live today, while audio, images, files and batch are labelled coming soon. Designing around that now prevents a customer-facing surprise later.
Honest comparison
| Concern | Plugsky | AI platform with built-in auth | Self-built stack |
|---|---|---|---|
| Customer OAuth | Runs in your product, tokens in your vault | Platform-managed connections | You build and maintain it |
| Model access | Scoped server-side keys per tenant | Platform session proxy | Your gateway and credentials |
| Entitlements | Enforced in your gateway and broker | Platform plan settings | Custom billing integration |
| API shape | OpenAI-compatible, keep your SDK | Vendor SDK | Anything you implement |
| Cost control | Flat monthly plans plus usage per key | Platform usage metering | Fully yours to model |
Frequently asked questions
Can our front end call Plugsky directly?
No. Keep the key server-side. Browser or mobile calls would expose a credential that spends your quota; proxy through your backend or an edge function.
How do we map plans to model access?
Resolve the tenant's plan in your broker and select a scoped key or quota bucket that matches it. Model allow-lists and limits stay in your gateway where you can change them without a deploy to the client.
Do we need SSO for our own team?
It helps as you grow. Console access supports SSO with SCIM provisioning, mapped to RBAC roles, so engineering, support and finance see only what they need.
How do we handle churn and revocation?
Revoke the tenant's keys when a subscription lapses, and rotate on a schedule. Because keys are per tenant and environment, revocation never affects other customers.
Is streaming available for chat features?
Yes. Chat completions support server-sent events, and function calling works alongside streaming for tool-based features.
What about customers with residency requirements?
Pin their workloads to a region-locked plane, or use VPC, on-prem or air-gapped deployment where required.
How do we test without committing?
Use the free plan with plugsky-micro and plugsky-lite and no card for development, then the 14-day full-access trial for a realistic load test.