KJClernt Games Platform V2

Build at the speed of thought.

KJClernt provides the core infrastructure for identity, access, and billing management. Integrate our APIs in minutes and scale to millions of users seamlessly.

High Performance

Global edge caching ensures < 50ms response times for all critical identity requests.

Enterprise Security

SOC2 Type II certified infrastructure with end-to-end encryption and zero-trust policies.

Modular Design

Only implement what you need. Auth, Billing, and User Management are decoupled.

Ready to jump in?

Head over to the Quickstart guide to make your first API request.

Quickstart Guide

Get up and running with the KJClernt SDK in less than five minutes. This guide will walk you through installing the client and making your first authentication request.

1 Install the SDK

We officially support Node.js, Python, and Go. Choose your preferred package manager to install the core library.

                                npm
                                yarn
                                pip
                            
                                $ npm install @VanduOS-io/sdk

2 Initialize the Client

Import the library and initialize it using your secret API key found in the developer dashboard.

import { VanduOSClient } from '@VanduOS-io/sdk';

const nexus = new VanduOSClient({
  apiKey: process.env.NEXUS_SECRET_KEY,
  environment: 'production'
});

3 Make your first request

Fetch your workspace details to verify the connection is working.

async function testConnection() {
  try {
    const workspace = await nexus.workspaces.retrieve();
    console.log("Connected to: ", workspace.name);
  } catch (error) {
    console.error("Auth failed:", error.message);
  }
}

Authentication

The Nexus API uses API keys to authenticate requests. You can view and manage your API keys in the Developer Dashboard.

Keep your keys safe

Your API keys carry many privileges, so be sure to keep them secure. Do not share your secret API keys in publicly accessible areas such as GitHub, client-side code, and so forth.

Bearer Tokens

Authentication to the API is performed via HTTP Basic Auth. Provide your API key as the basic auth username value. You do not need to provide a password.

curl https://api.nexus.io/v1/users \
  -H "Authorization: Bearer nx_live_89234798237498"

Key Environments

Prefix	Environment	Description
nx_test_	Sandbox	Used for testing. No real charges are made.
nx_live_	Production	Live mode. Impacts actual data and processes real payments.

API Reference Users API

Users API

Manage user accounts, identities, and metadata.

Create a User

POST https://api.nexus.io/v1/users

curl -X POST https://api.nexus.io/v1/users \
  -H "Authorization: Bearer nx_test_key" \
  -H "Content-Type: application/json" \
  -d '{ "email": "dev@nexus.io", "name": "Developer" }'

API Reference Billing API

Billing API

Create subscriptions, handle invoices, and manage payment methods.

Create a Subscription

Subscribes a user to a specific pricing plan. Requires a valid payment method attached to the user.

POST /v1/billing/subscriptions

{
  "user_id": "usr_982347",
  "plan_id": "plan_pro_monthly",
  "trial_period_days": 14
}

Webhooks

Listen for asynchronous events occurring within your Nexus workspace.

Verifying Signatures

Nexus signs the webhook events it sends to your endpoints by including a signature in each event's Nexus-Signature header. This allows you to verify that the events were sent by Nexus.

const crypto = require('crypto');

function verifySignature(payload, signatureHeader, secret) {
  const hash = crypto
    .createHmac('sha256', secret)
    .update(payload)
    .digest('hex');
  
  return hash === signatureHeader;
}

Errors & Rate Limits

Code	Description
200 - OK	Everything worked as expected.
400 - Bad Request	The request was unacceptable, often due to missing a required parameter.
401 - Unauthorized	No valid API key provided.
429 - Too Many Requests	You have hit your rate limit. Wait before sending more requests.

Rate Limits

The Nexus API allows 100 requests per second on the standard tier. Check the headers X-RateLimit-Remaining on your responses.

Engineering Blog

Deep dives into architecture, performance, and building Nexus.

Architecture

Scaling Infrastructure to 1M WebSockets

A technical deep dive into how we re-architected our core routing layer using Rust and Redis.

Security

Implementing Zero-Trust Architecture

How we overhauled internal node communication to require strict mTLS authentication.

Architecture

Scaling Infrastructure to 1M WebSockets

Sarah Chen

Lead Platform Engineer • Oct 24, 2024

When we first launched Nexus, our real-time notification engine was built on a standard Node.js and Socket.io stack. It worked perfectly for our first 10,000 concurrent users. But as we scaled to enterprise clients, the cracks began to show.

The Problem with Node.js at Scale

Node.js is fantastic for I/O bound tasks, but keeping hundreds of thousands of active TCP connections open eats up memory fast. We were experiencing massive garbage collection pauses that caused connection drops.

"We were throwing servers at the problem. Our AWS bill tripled, but our stability actually decreased due to cross-node syncing issues."

The Rust Rewrite

We decided to write a thin, highly optimized proxy layer in Rust using the tokio runtime. This layer handles nothing but holding the TCP connections open and verifying JWTs.

// A snippet of our connection handler in Rust
async fn handle_connection(stream: TcpStream) {
    let ws_stream = accept_async(stream).await.expect("Failed to accept");
    println!("New WebSocket connection established");
    // Minimal memory footprint per connection
}

The results were staggering. A single Rust server could comfortably hold 250,000 connections using less than 2GB of RAM. We reduced our fleet from 40 instances down to 4.

Security

Implementing Zero-Trust Architecture

Marcus T.

Head of Security • Oct 18, 2024

Historically, securing a backend meant building a strong perimeter (the "castle-and-moat" model). Once a request passed the API gateway, it was trusted implicitly by internal microservices. This is no longer enough.

What is Zero-Trust?

Zero-trust means assuming the network is already compromised. Every single internal request between our microservices must be authenticated and authorized, just as if it came from the public internet.

mTLS Everywhere

We rolled out mutual TLS (mTLS) across our entire Kubernetes cluster using an Istio service mesh. Now, not only does the server prove its identity to the client, but the client (another microservice) must prove its identity to the server using a cryptographically signed certificate.

Certificates are rotated every 24 hours automatically.
No service can bypass the mesh proxy.
All internal traffic is AES-256 encrypted.

Achieving our SOC2 Type II compliance was significantly streamlined because we could mathematically prove that lateral movement by a bad actor inside our network was virtually impossible.