SECURITY
Platform security for realtime messaging
Authenticate every REST and Socket call with project keys or tokens. Traffic uses encrypted transport across the global edge before it reaches your channels and queues.
import { QPub } from "@qpub/sdk";
new QPub.Rest({ apiKey: "…" });
new QPub.Socket({ apiKey: "…" });Auth on every path
Publish, subscribe, and enqueue require valid credentials scoped to your project.
Every request is authenticated
Clients connect over TLS to edge infrastructure. Credentials are validated before channel or queue operations run — the same model for browsers, servers, and workers.
- API keys for server-side and REST integrations
- Token flows for user-scoped Socket connections
- No anonymous publish or subscribe on production keys
Least privilege by project
Keys and tokens belong to a QPub Cloud project. Channel and queue access stays inside that boundary so staging and production never share credentials by accident.
- Rotate keys from the Cloud console
- Separate projects per environment
- Same auth surface for Channels and Queues
What you control
- ·API key storage and rotation
- ·Token issuance for end users
- ·Channel and queue naming conventions
- ·Which clients receive credentials
What QPub operates
- ·TLS for client and edge transport
- ·Platform patches and edge capacity
- ·Auth validation on the messaging API
- ·Operational status and incident comms
Frequently asked questions
- API keys or tokens — which do I use?
- Use API keys for trusted servers and REST. Use token flows when end-user clients connect over Socket and you need per-user scope. Details are in the authentication guide.
- Is REST auth the same as Socket auth?
- Both require valid project credentials. REST sends keys or bearer tokens on each request; Socket authenticates during connection setup, then reuses the session.
- Where do I see limits and pricing?
- Plans define concurrent usage and message volume. Compare options on the pricing page or in QPub Cloud after signup.
Ship with confidence
Trust Built In