Worker — data plane

CORE PRODUCT

One gateway. HTTP, gRPC, WebSocket, and AI.

The Apinizer API/AI Gateway is a stateless, high-concurrency runtime that handles every API call in your platform — REST, SOAP, gRPC, WebSocket, GraphQL, and AI traffic. Per-request context, async logging, and hot deploy without restarts.

Request a demo Read the docs

Apinizer API Management Platform overview

Inside the Manager

Every API proxy, one console.

Browse, filter, and govern every API proxy from a single Manager UI — across protocols, environments, and teams. The list below is a real screenshot from production deployments.

Apinizer Manager — API Proxies list with protocol, environment, and policy controls — Apinizer Manager · API Proxies list · production screenshot

Capabilities · deep dive

Eight capability areas. One Worker. Same policy surface for API and AI.

Authentication, advanced cryptography, traffic management, multi-protocol routing, mediation, lifecycle, observability — and AI traffic on the same gateway. Each capability is a real Apinizer policy or runtime feature, not a roadmap promise.

01 · Authentication & identity

Nine authentication methods. One policy surface.

Apinizer enforces auth before routing — modern OAuth 2.0 / OIDC / JWT alongside enterprise mTLS, SAML, and the Basic / Digest flows still living in your legacy estate. Every method ships as a first-class policy with a UI, not a plugin you have to write.

OAuth 2.0 (client credentials, password, code, refresh) and OIDC validation
JWT — including third-party JWT — with rotating JWKS support
mTLS with PKI-backed client certificates and HSM integration
SAML, Basic, Digest, Base64 auth for the legacy partners that still need them
Per-policy variable resolution — never raw fields, no cross-request leaks

oauth-2-auth
oidc-auth
jwt-auth
jwt-3rd-party-auth
policy-mtls-authentication
saml-validation
basic-auth
digest-auth
base64-auth

Same lane for AI

Agent traffic uses the same Identity Manager — every LLM call carries an OAuth-scoped token bound to a Project, not a shared API key.

Authentication policy designer — OAuth 2.0 selected, with token URL, client ID, scope, and audience fields, plus chips for the eight other supported methods.

02 · Advanced cryptography & signing

WS-Security, JOSE, and digital signing — without bolt-ons.

For banks fronting partner SOAP services and ministries running signed XML exchange, the gateway carries the full WS-Security suite plus JOSE encryption / signing for JSON. Sign, encrypt, and validate at the edge, with HSM-backed certificates the auditor can trace.

WS-Security: sign body, encrypt body, username token, timestamp, STS, sign validation
JOSE: JWS + JWE validation and implementation for modern JSON exchange
Standalone encryption / decryption + digital sign / verify policies
FIPS-compatible algorithms (RSA-SHA256/512, ECDSA, AES-256-GCM, AES-CBC)
Field-level redaction at egress — masked for tier<ADMIN, in plain in audit

policy-ws-security-sign
policy-ws-security-encrypt
policy-ws-security-username
policy-ws-security-timestamp
policy-jose-validation
policy-jose-implementation
policy-encryption
policy-decryption
policy-digital-sign
redaction

Same lane for AI

Same redaction policies sanitize PII out of LLM prompts and responses — no separate AI redaction stack to operate.

Advanced cryptography panel — WS-Security tab active with sign and encrypt body checked, RSA-SHA256 and AES-256-GCM algorithm selectors, HSM-backed certificate selected.

03 · Traffic management & quotas

Rate limit, throttle, quota — at the API, role, or subscriber level.

Apinizer's RLCL (Rate Limit · Caching · Logging) policies give you granular control over every request. Per-API throttling, per-subscriber quotas, IP allow- and deny-lists, message-size caps, and an Allowed Hours policy for partners that should only call between 09:00–18:00.

API throttling and per-subscriber quota with burst windows
Endpoint rate limit policies on individual paths
Min and max message size enforcement (XXE / oversize-body protection)
IP white / black lists and content filtering for known bad patterns
Allowed Hours policy — partner contracts that only run during business hours

api-based-throttling
api-based-quota
policy-endpoint-rate-limit
max-message-size
min-message-size
ip-white
ip-black
content-filter
allowed-hours

Same lane for AI

Token-based rate limiting joins the same surface — limit by tokens-per-minute or cost-per-team, not just requests.

Traffic management dashboard — live RPS at 1,243, P99 latency 28ms, throttled at 3.4%, with a 30-minute RPS chart and top consumers list with quota progress bars.

04 · Multi-protocol routing

HTTP, gRPC, WebSocket, SOAP, GraphQL — one Worker, one runtime.

Three first-class routing handlers sit on a single Undertow loop: HttpRoutingHandler, GrpcRoutingHandler, WebSocketRoutingHandler. SOAP-as-REST, GraphQL proxy, Server-Sent Events, MQTT and Kafka bridges round out the protocol coverage. No second runtime, no second observability stack.

HTTP/1.1 and HTTP/2 with full streaming and content compression
Native gRPC — unary plus bidirectional streams, transcoding gRPC ↔ REST
WebSocket with sub-protocol negotiation and TLS (WSS)
SOAP / WSDL primed at deploy — exposed as REST or gRPC for modern consumers
GraphQL proxy, Server-Sent Events, MQTT and Kafka bridges

HTTP/1.1
HTTP/2
gRPC
WebSocket (WSS)
SOAP / WSDL
GraphQL
SSE
MQTT
Kafka
LLM (AI)

Same lane for AI

The OpenAI-compatible /ai/v1/chat/completions endpoint is just another route — same Worker, same audit, same RBAC.

Multi-protocol route editor — HTTP tab active, path /api/v1/customers/{id}/transactions, GET and POST methods enabled, all 10 protocols listed including LLM (AI) on the same worker.

05 · Mediation & transformation

SOAP ↔ REST, XML ↔ JSON — visually, without the rewrite.

Translate between contracts at the gateway: JOLT for JSON shape changes, XSLT for XML, Groovy and JavaScript when you need code, Message Builder for response synthesis, and standalone Redaction for the fields auditors care about. Every transform runs in milliseconds with variables resolved through a single API.

Protocol transformation request / response (SOAP ↔ REST, REST ↔ gRPC)
JOLT for JSON shape changes, XSLT for XML transforms
Groovy and JavaScript script policies for the cases that need code
Message Builder — synthesize responses from upstream calls
Redaction policy — mask fields at egress without losing them in audit

protocol-transformation-request
protocol-transformation-response
policy-json-transformation
policy-xml-transformation
script (Groovy / JS)
message-builder
redaction

Same lane for AI

Transformation policies also reshape LLM payloads — vendor-specific request bodies normalized to the OpenAI-compatible facade.

Visual transformation designer — SOAP/XML source on the left, REST/JSON target on the right, JOLT spec preview at the bottom with field-level redaction policy applied.

06 · API lifecycle & mock

Versioning, mocks, and schema validation — primed at deploy.

Run multiple API versions in parallel with traffic-split routing — canary 8%, stable 87%, deprecated 5%. Mock APIs for partners testing v2.0-beta. JSON Schema and XML XSD validators are primed at deploy time, never on first request.

Run multiple API versions in parallel — traffic split, canary, blue-green
Mock API responses for partners and pre-prod testing
JSON Schema validation primed at deploy — no first-request penalty
XML XSD validation for SOAP routes — same warm-up guarantee
Hot deploy: routing tables, marshalled routes, and load balancer flush atomically

json-schema-validation
xml-schema-validation
business-rule
Hot deploy
Canary release
Blue-green
Mock API

Same lane for AI

AI Gateway routes ship through the same versioning — pin a model to v1.1 while v2.0-beta tests a cheaper provider.

API lifecycle panel — payments-api with v1.0 deprecated (5% traffic), v1.1 stable (87% traffic, 1,082 RPS), v2.0-beta canary (8% traffic), and mock + schema validation toggles enabled.

07 · Observability & audit

Async logging that never blocks the request path.

Traffic logs are emitted via CompletableFuture.runAsync() onto a dedicated executor — the request path stays cold, the log path stays out of the way. Every request, header rewrite, policy execution, and routing decision lands in Elasticsearch, queryable side-by-side with your gRPC and LLM traffic.

Async traffic logging — request path never waits on the log writer
MessageContext per request — never shared, MDC cleared in finally{}
Real-time anomaly detection (EMA + Bollinger Band) with multi-channel alarms
Certificate watchdog — partner cert expiries surface 14 days ahead
Audit trail enforced by the persistence layer — bypass rejected at compile time

policy-log
Elasticsearch
Anomaly detection
Certificate watchdog
Audit aspect
MDC per request

Same lane for AI

Token usage, cost-per-team, and prompt-firewall hits land in the same Elasticsearch index — one query for API + AI behavior.

Live traffic stream — seven request rows showing GET, POST, gRPC, WS, and LLM traffic with status codes and P99 latency, plus an anomaly sidebar with three open alerts (P99 spike, 429 surge, certificate expiry).

08 · AI traffic on the same gateway

Multi-LLM routing with token quotas and a prompt firewall.

The same gateway that fronts your REST and gRPC APIs governs every LLM call. 17+ providers behind one OpenAI-compatible facade — switch on cost, latency, or per-prompt classification without rewriting the application. Token quotas, semantic caching, and prompt firewalls are policies, not external services.

OpenAI-compatible facade across 17+ providers (OpenAI, Anthropic, Bedrock, Azure, Gemini, Cohere, …)
Weighted multi-LLM routing — cost / latency / per-prompt classification
Token-based rate limiting — TPM and RPM per user / API key / team
Semantic caching for repeat prompts — drop spend on hot queries
Prompt firewall: jailbreak guard, PII redaction, off-topic / cost guards