QuickZTNA developer documentation

This is the developer reference for QuickZTNA. It documents the contract between your systems and ours: the CLI surface, the REST API, the cryptographic model, the SSO integration shape, and the security commitments we make.

The docs assume you’re already comfortable with the product. If you’re not yet — if you haven’t installed a client and connected two devices — the user guide is the better starting point. It’s faster to read and gets you to a working network in two minutes.

What’s here

Concepts: Zero Trust and post-quantum cryptography. The mental model. Why Zero Trust replaces VPN, why mesh replaces hub-and-spoke, what hybrid post-quantum key exchange is and why it matters now. If you have to explain QuickZTNA to a CISO, security architect, or engineering leader, this page is the briefing material.

CLI command reference. Every command, every flag, every exit code. The CLI is the same on Linux, macOS, and Windows; differences where they exist are called out per-command.

REST API overview. Authentication, versioning, pagination, rate limits, error format, and the endpoint catalogue. The full OpenAPI specification is at https://login.quickztna.com/api/openapi.json; this page is the human-readable companion.

Security model. The cryptographic primitives in use, the trust model, the posture engine, audit logging, compliance posture (SOC 2, FIPS 203, GDPR), and the coordinated-disclosure policy for security researchers.

SSO integrations. Setup details for OIDC, Google Workspace, Microsoft Entra (formerly Azure AD), GitHub, Okta, and Authentik. Plus SAML notes and the SCIM provisioning surface.

How these docs are organized

Each section is one page. We’ve made a deliberate choice to write fewer, deeper pages rather than many thin ones — the developer audience for these docs is technical enough to use a table of contents, and a single long page beats fifteen small ones for Ctrl+F navigation.

Every page has a table of contents on the right rail (desktop) or inline at the top (mobile). Every code example is copy-paste runnable; if it isn’t, that’s a docs bug and we want to know.

Spec snapshot

For people scanning to confirm the technical particulars before reading further:

Cryptographic primitives. Hybrid X25519 + ML-KEM-768 (FIPS 203) for key exchange on every tunnel, every plan. ChaCha20-Poly1305 AEAD for data plane. HKDF-SHA256 for key derivation with transcript binding. Ed25519 for device identity signatures. SHA-256 for content hashing.

Identity. OIDC primary; SAML supported for enterprise plans; SCIM 2.0 for user/group sync on Business and Workforce. Per-user MFA enforced through your IdP — QuickZTNA does not maintain a separate password.

API. REST over HTTPS with bearer tokens. OpenAPI 3.1 specification. JSON request and response bodies. RFC 7807 error format. Rate-limited per organization with documented limits.

Compliance. SOC 2 Type II report available under NDA. GDPR-compliant with documented data flows. FIPS 203 conformant for ML-KEM-768. ISO 27001 in progress (target 2026 Q3).

Audit. Every administrative action, every policy decision, and every authentication is logged. Free plan: 90-day retention with dashboard query. Business: one year, queryable via API, exportable to SIEM. Workforce: customizable retention, real-time streaming to your log infrastructure.

Self-hosting. Available on the Workforce plan. The control plane runs as a small set of services on your infrastructure with documented requirements. Client binaries are unchanged between managed and self-hosted deployments.

A note on stability

The CLI and REST API follow semantic versioning. Breaking changes to either surface are announced 90 days in advance via the status page (status.quickztna.com), the release notes, and email to organization admins. Deprecated endpoints and flags continue to function during the deprecation window and emit deprecation warnings.

Internal protocols — the wire format between the client and the coordination service — do not have a stability commitment; they’re versioned and negotiated transparently. You should not build automation that assumes the on-wire protocol is stable, because it isn’t (and doesn’t need to be — the documented surfaces are stable enough that you never need to peek under the hood).

How to read these docs

If you’re evaluating QuickZTNA technically, read Concepts and Security first. Those answer the “is this product credibly Zero Trust and post-quantum” question, with citations to NIST, IETF, and other primary sources where appropriate.

If you’re integrating QuickZTNA into a CI/CD pipeline or other automation, the CLI and API pages are your reference. The CLI is the easiest entry point for shell scripts; the API is what you want for anything that needs to react to events or query state in bulk.

If you’re plugging QuickZTNA into your identity provider, the Integrations page covers the setup specifics for the common IdPs. The patterns are similar across providers but each has a few peculiarities worth knowing.

For operator-level “how do I do X,” cross-reference to the user guide — every page has a “what’s next” link to the relevant operator content.

Updates and changelog

These docs are updated as part of every client release. The “Last updated” timestamp at the top of each page reflects the last meaningful content change (not just a typo fix). For a chronological view of what’s changed, the release notes at https://quickztna.com/blog/ (filed under the “Release notes” category) document every released change to clients, the API, and the service.

If you find an error in the docs — a wrong exit code, a stale endpoint description, an example that doesn’t run — please tell us at support@quickztna.com. We treat docs bugs as product bugs and fix them on the same cadence.

Contact

For technical questions about anything in these docs, support@quickztna.com is the right place. Free plan support is best-effort; Business and Workforce plans have documented response-time SLAs.

For security issues — vulnerabilities, suspected key compromise, anything that should not be discussed publicly — security@quickztna.com is the right channel. Our coordinated-disclosure policy is on the security page.

For SSO and integration questions specifically, the Integrations page covers the common providers and points to the right support contact for your IdP-specific questions.

Ready? Start with concepts →