Smart API routing
Route by service, API version, environment, tenant, entitlement or current license state — and change any of it without redeploying a single client.
One secure entry point for authentication, licensing, policy enforcement, routing and observability across your WordPress plugins, SaaS products and internal services.
/v1/gateway/request
// Client sends license context, never provider secrets
{
"license_key": "MBL-••••-••••-4A7F",
"service": "trangpc-ai",
"action": "generate",
"client": {
"app": "wordpress",
"version": "1.4.0",
"env": "production"
}
}
// Evaluated by MB License Management
{
"license": "active",
"entitlement": "pro",
"scope": "wordpress:production",
"quota": {
"used": 4820,
"limit": 10000,
"resets_in": "11d"
},
"signature": "valid",
"decision": "allow"
}
// 200 OK · 42 ms
{
"request_id": "req_A71F3C",
"status": "ok",
"routed_to": "trangpc-ai:v2",
"usage": {
"remaining": 5180
},
"data": {
"output": "…"
}
}
200 OK
One policy plane across the TrangPC ecosystem
99.95 %
Availability target
Design goal for the policy plane
< 50 ms
Policy decision budget
Overhead added before routing
100 %
Decisions audited
Every allow, deny and throttle
0
Secrets in client code
Upstream credentials stay server-side
Figures describe design targets for the platform, not measured production results. Replace them with your own verified numbers before launch.
Move sensitive decisions out of distributed client code and into a centralized boundary designed around licensing, access policy and operational visibility.
Route by service, API version, environment, tenant, entitlement or current license state — and change any of it without redeploying a single client.
API keys, license keys, request signatures and access decisions live behind one consistent control point instead of being scattered across every consumer.
Apply request limits by plan, customer, service, feature entitlement or billing period.
Absorb bursts and reduce abuse before suspicious traffic ever reaches a protected upstream service.
Run several API versions side by side and migrate consumers on their own schedule.
Upstream URLs, provider tokens and internal routing rules never ship inside a distributable plugin package.
Request IDs, policy outcomes, response codes and latency are recorded together, so operations teams investigate with evidence instead of guesses.
A valid activation is only the beginning. The gateway evaluates license status, entitlements, environment, client scope and usage policy before every protected operation.
The plugin or application sends its license context, client identity, requested service and request metadata — nothing else.
Activation status, entitlement, allowed scope, remaining quota and security conditions are checked together before access is granted.
Compliant requests continue to the protected service. Everything else stops at the policy boundary and is recorded with a reason.
This page presents a security-first architecture without pretending that a user interface secures an API. Real enforcement lives in the gateway and the MB License Management backend.
Signatures and timestamps strengthen trust between supported clients and the gateway.
Rotate server-side credentials without shipping a new secret to every installed client.
Reject stale or previously accepted signed requests when your policy requires it.
Combine per-license quotas with rate limits to protect expensive upstream workloads.
Every policy decision carries a request identifier for review and incident analysis.
Upstream URLs, provider tokens and routing logic stay out of distributable code.
Your distributed plugins and applications call TrangPC API Gateway. Provider credentials and licensing decisions never leave the server.
# Example contract — replace with your production endpoint
curl -X POST https://api.trangpc.vn/v1/request \
-H "Content-Type: application/json" \
-H "X-License-Key: $TRANGPC_LICENSE_KEY" \
-H "X-Client-Id: $TRANGPC_CLIENT_ID" \
-d '{
"service": "trangpc-ai",
"action": "generate",
"payload": { "prompt": "Hello TrangPC" }
}'
// Inside your plugin — no upstream provider key required.
$response = wp_remote_post( 'https://api.trangpc.vn/v1/request', [
'timeout' => 20,
'headers' => [
'Content-Type' => 'application/json',
'X-License-Key' => $license_key,
'X-Client-Id' => $client_id,
],
'body' => wp_json_encode( [
'service' => 'trangpc-ai',
'action' => 'generate',
'payload' => [ 'prompt' => $prompt ],
] ),
] );
if ( is_wp_error( $response ) ) {
return $response;
}
$body = json_decode( wp_remote_retrieve_body( $response ), true );
// Server-side only. Never ship a license key to the browser.
const res = await fetch('https://api.trangpc.vn/v1/request', {
method: 'POST',
headers: {
'Content-Type': 'application/json',
'X-License-Key': process.env.TRANGPC_LICENSE_KEY,
'X-Client-Id': process.env.TRANGPC_CLIENT_ID,
},
body: JSON.stringify({
service: 'trangpc-ai',
action: 'generate',
payload: { prompt },
}),
});
if (!res.ok) {
// 401 license, 403 entitlement, 429 quota — handle each distinctly.
throw new Error(`Gateway rejected: ${res.status}`);
}
const data = await res.json();
# Load credentials from the environment, not from source control.
import os, requests
resp = requests.post(
"https://api.trangpc.vn/v1/request",
headers={
"X-License-Key": os.environ["TRANGPC_LICENSE_KEY"],
"X-Client-Id": os.environ["TRANGPC_CLIENT_ID"],
},
json={
"service": "trangpc-ai",
"action": "generate",
"payload": {"prompt": prompt},
},
timeout=20,
)
resp.raise_for_status()
data = resp.json()
Presentation example. The endpoint, headers and payload above illustrate the integration shape. They are not a claim about your current live API contract — publish your verified contract before customers build against it.
Standardize how different products reach protected capabilities while preserving the entitlements that make each product distinct.
Reach AI, update, content and private services from a plugin you ship publicly, without embedding upstream credentials in the package.
Integration patternEvaluate access by tenant, plan, entitlement, usage quota and environment before any protected operation runs.
Licensing modelHide provider credentials behind one controlled API and apply per-license limits around expensive inference workloads.
Security modelEvery tier is enforced by the same policy engine. What changes is scope, quota and the depth of the security controls available to you.
For a single product or a first integration behind the gateway.
For distributed plugins and SaaS products with real customer load.
For teams with custom policy, compliance or isolation requirements.
Tier contents describe entitlement scope, not a published price list. Confirm commercial terms before you rely on them.
Straight answers about the role of the gateway, MB License Management and this presentation layer.
Centralize access control, licensing policy and service routing without exposing your internal architecture to every client you ship.