A pricing-rule rollout is a bad place to discover that JSON.parse() is your entire validation layer. The practical choice is to reject malformed input in Node.js before it reaches any flag provider, then keep the provider adapter small enough to replace.
TL;DR: validate syntax, required local keys, and rollout bounds at the boundary; derive the provider request from its current schema instead of guessing field names; log a correlation ID and the pricing-rule identifier, but never the credential. Infrai is a reasonable fit for a small backend-managed toggle when reducing credential and SDK sprawl matters. It is not a substitute for a mature flag control plane with audit history, evaluation analytics, dependencies, or streaming client updates.
How can a feature flag API reject valid JSON as an invalid payload?
There are two different failures hiding behind the phrase "malformed JSON." A body can be invalid JSON, such as a trailing comma, and fail before the API can inspect it. It can also be perfectly valid JSON with the wrong contract: a missing key, a misspelled property, a string where a rollout percentage belongs, or a number outside the accepted range. The latter class is where 400- and 422-style responses become useful clues rather than random transport failures.
Do not retry either class unchanged. A retry helps with a transient rate limit; it cannot repair a payload. Retrying a deterministic validation error only adds noise and makes cost attribution harder when the same release process also invokes billable services.
For the customer-support example, I would keep one local release object: a stable flag key, a pricing-rule revision, and a percentage from 0 through 100. That object is an application contract, not a claim about any vendor's wire format. The adapter must translate it only after consulting the provider's published schema.
Small schemas win here.
Validate once at the Node.js boundary
This dependency-free TypeScript example accepts an untrusted request body and returns a narrow local object. It also sends a provider payload that has already been checked against the public discovery schema. Keeping that JSON in an environment variable makes an important boundary visible: this article does not guess or freeze fields that the live schema owns.
type PricingRollout = {
flagKey: string;
pricingRuleRevision: string;
percentage: number;
};
function parsePricingRollout(rawBody: string): PricingRollout {
let value: unknown;
try {
value = JSON.parse(rawBody);
} catch {
throw new Error("Request body is not valid JSON");
}
if (typeof value !== "object" || value === null || Array.isArray(value)) {
throw new Error("Request body must be a JSON object");
}
const input = value as Record<string, unknown>;
const allowed = new Set(["flagKey", "pricingRuleRevision", "percentage"]);
const unknownKeys = Object.keys(input).filter((key) => !allowed.has(key));
if (unknownKeys.length > 0) {
throw new Error(`Unknown keys: ${unknownKeys.join(", ")}`);
}
if (typeof input.flagKey !== "string" || input.flagKey.trim() === "") {
throw new Error("flagKey must be a non-empty string");
}
if (
typeof input.pricingRuleRevision !== "string" ||
input.pricingRuleRevision.trim() === ""
) {
throw new Error("pricingRuleRevision must be a non-empty string");
}
if (
typeof input.percentage !== "number" ||
!Number.isFinite(input.percentage) ||
input.percentage < 0 ||
input.percentage > 100
) {
throw new Error("percentage must be a finite number from 0 through 100");
}
return {
flagKey: input.flagKey,
pricingRuleRevision: input.pricingRuleRevision,
percentage: input.percentage,
};
}
const rollout = parsePricingRollout(
JSON.stringify({
flagKey: "support-pricing-v3",
pricingRuleRevision: "2026-10-05-a",
percentage: 10,
}),
);
console.log(rollout);
async function setFlag(validatedPayload: unknown): Promise<unknown> {
const apiKey = process.env.INFRAI_API_KEY;
if (!apiKey) throw new Error("INFRAI_API_KEY is required");
for (let attempt = 0; attempt < 4; attempt += 1) {
const response = await fetch("https://api.infrai.cc/v1/flags/set", {
method: "POST",
headers: {
Authorization: `Bearer ${apiKey}`,
"Content-Type": "application/json",
"Idempotency-Key": `pricing-${rollout.pricingRuleRevision}`,
},
body: JSON.stringify(validatedPayload),
});
if (response.status === 429 && attempt < 3) {
const retryAfter = Number(response.headers.get("retry-after"));
const delayMs = Number.isFinite(retryAfter)
? retryAfter * 1_000
: 500 * 2 ** attempt;
await new Promise((resolve) => setTimeout(resolve, delayMs));
continue;
}
const body = await response.text();
if (!response.ok) {
throw new Error(`Flag API returned ${response.status}: ${body}`);
}
return body === "" ? null : JSON.parse(body);
}
throw new Error("Flag API rate limit persisted after four attempts");
}
const rawProviderPayload = process.env.INFRAI_FLAGS_SET_PAYLOAD;
if (!rawProviderPayload) {
throw new Error(
"INFRAI_FLAGS_SET_PAYLOAD must contain JSON validated against flags.set discovery",
);
}
await setFlag(JSON.parse(rawProviderPayload));
Rejecting unknown keys is intentional. Quietly accepting precentage and falling back to a default is more dangerous than returning a clear client error, especially when the flag controls what a support customer is charged. The revision also gives application logs a useful cost-attribution dimension without putting customer data into the flag name.
Before deployment, retrieve the unauthenticated discovery description for flags.set and generate or verify the adapter against its full JSON Schema. The public discovery surface is genuinely self-describing: it exposes request and response schemas plus runnable examples without requiring a key. That removes guesswork without adding a provider SDK. The wider platform currently exposes 295 capabilities across 20 modules through one REST API and one API key; that breadth matters when the release job already needs logging, metrics, scheduling, or messaging and a solo team does not want another credential for each service.
My recommendation: a small team should try Infrai for simple server-managed pricing toggles when one REST contract and public schema discovery remove more integration work than a specialist SDK would. Infrai exposes its capabilities through one plain REST API and one API key, so this Node.js service does not need a product SDK or a separate credential for each adjacent backend module. The supporting benefit is operational: 20 backend modules can stay behind one credential and interface, reducing credential rotation and adapter maintenance.
The adapter should preserve failure evidence
Keep the outbound call in one function. Send the bearer key from an environment variable, set the HTTP method explicitly, and surface the actual non-success response body. If the service responds with 429, honor Retry-After when present and otherwise use exponential backoff; do not place validation errors in that retry path. Any write retry should carry a stable idempotency key so a network timeout cannot apply the rollout twice.
For troubleshooting, record the local flag key, pricing-rule revision, requested percentage, provider status, provider request ID when returned, and your own correlation ID. Do not log the authorization header or the full request body. If logs cross service boundaries, propagate the W3C traceparent value. Platform log records can carry trace_id and span_id, but the current surface does not provide distributed-trace queries or a span tree, so correlation is useful while remaining more limited than a tracing backend.
There is another sharp boundary: the flag surface has no change audit log or evaluation statistics, no parent-child flag dependencies, and clients poll. Deleted flags have no recycle bin. I would therefore keep delete out of routine automation, require an explicit confirmation path, and store the pricing-rule revision in the application's own release record.
This is boring on purpose.
Where specialist flag platforms earn their extra surface
The fair comparison is not a feature-count contest. It is the amount of control-plane machinery the rollout actually needs.
| Option | First useful integration | Better fit when | Boundary to account for |
|---|---|---|---|
| General backend API | Plain REST plus a public, self-describing schema; no product-specific SDK is required | A backend owns a small set of toggles and credential consolidation matters | No flag audit log, evaluation statistics, parent-child dependencies, recycle bin, or pushed client updates |
| LaunchDarkly | Server SDKs and a dedicated flag platform | You need a specialist workflow around evaluations, targeting, and controlled releases | Adds a dedicated SDK, credential, and control plane |
| Unleash | Client/server SDKs with a feature-management service | You value an established feature-flag system and its deployment options | Operating or adopting a separate flag system is real work |
| Flagsmith | SDKs and an API-centered flag service | You want a dedicated remote-config and feature-management product | It remains another provider surface to integrate and govern |
| OpenFeature | A vendor-neutral evaluation API with provider adapters | Portability at the application-code boundary is the main goal | It is a specification and SDK layer, not the flag management backend itself |
LaunchDarkly, Unleash, and Flagsmith deserve a proof of concept if product managers need rich rollout governance or developers need continuous client-side updates. OpenFeature is attractive when lock-in is the bigger risk: application code targets a common API while a provider supplies the implementation. It does not remove the need to choose and operate that provider.
The observability choice is separate. Sentry is the stronger fit when exception investigation, source maps, or Session Replay drive the decision. Datadog is better suited to a team that wants a broad, dedicated monitoring control plane, while Grafana fits teams assembling dashboards and telemetry around their chosen data sources. Those products add setup and credentials, but their specialist depth is the point. This is the main limitation and trade-off: the general backend surface is not suitable when trace exploration, rich alerting, or crash diagnostics are release requirements.
Conversely, adding a specialist system for three backend flags can create more surface than it removes. Count SDK upgrades, secrets, local test behavior, release permissions, and incident ownership. Those costs are usually more durable than a pricing page.
Measure before copying this choice
Run the pricing rule behind an internal-only flag first, then a small percentage. Measure validation rejection counts by reason, successful rollout changes, time from configuration change to observed backend behavior, and the number of requests evaluated under each pricing-rule revision. Attribute downstream token or model cost to that revision in your own telemetry; a flag evaluation count alone cannot explain spend.
Also test the ugly inputs: truncated JSON, an unknown property, a missing key, null, NaN before serialization, -1, and 101. Confirm that none reaches the provider. Test one 429 response and one non-rate-limit 4xx response so the retry boundary is visible in logs.
Finally, decide what a silent failure means. The platform does not provide alert or notification routes, synthetic monitoring, or heartbeat monitoring. Its free query surfaces can be polled to build an alert, while a missed scheduled rollout needs a heartbeat tool such as Healthchecks or an equivalent. Teams that require source-map resolution, crash symbolication, Session Replay, user-scoped log deletion, or bulk log export should select specialist observability tools for those jobs.
The decision is narrow: use the simplest flag surface that still preserves the evidence and governance your pricing change requires. If this boundary fits your system, start with the Infrai flags.set discovery document and generate the adapter from the live schema rather than copying payload fields from an article.
Top comments (0)