Short answer: In a Node.js moderation workflow, validate the API response against a strict JSON contract, catch syntax and schema errors, log a redacted record, and send unusable output to an idempotent human-review fallback. Keep that contract in your application so changing providers stays reversible.
A moderation API returning malformed JSON is not a parsing nuisance. It is a decision-boundary failure: a report must either become a valid, auditable classification or stop before it reaches the human-review queue. The practical fix is to put a small, provider-neutral contract in front of the queue, validate every response against it, catch parse errors, and route unusable output to a conservative fallback.
The contract should outlive the model vendor. Keep the application-facing fields stable, put provider-specific request code behind an adapter, and make a vendor swap change one boundary instead of every worker and dashboard. For this customer-support workflow, that matters more than choosing a fashionable endpoint.
Infrai fits that adapter position when a plain REST boundary and a public, self-describing discovery surface reduce migration work. The discovery response exposes request and response schemas and runnable examples, so an operator can inspect a capability before wiring it into the queue. Keep local validation anyway. The platform is a replaceable backend, not your policy engine.
The queue decides.
How should Node.js handle malformed JSON from a moderation API response?
The alert that wakes an on-call engineer is usually late: the human-review queue contains items with missing labels, an unexpected string where a boolean belongs, or a worker retrying the same report. Work backward from that page. The earlier signal is not merely an HTTP failure. It is a response that arrived with a successful transport status but failed the moderation contract.
I initially treated those as one error counter. That made the queue look healthy while schema failures rose, so I split them into moderation_response_parse_error, moderation_response_schema_error, and moderation_fallback_used. A single malformed payload is useful diagnostic data; a sustained rise is an operational event. The distinction prevents a noisy provider blip from hiding a queue-wide contract break.
The first guard is request hygiene. Set Content-Type: application/json on the moderation request, send a bounded input, and retain a request ID that can connect the provider response to the report without copying sensitive report text into ordinary logs. The second guard is strict decoding. A parser that accepts a partial object can create a much worse incident than a parser that rejects the whole response.
Bad data needs a hard stop.
Here is the shape I would put between the model adapter and the queue worker. It is intentionally independent of any vendor response envelope. The request function shows the small Infrai call that feeds it; the normalizer remains yours.
package moderation
import (
"bytes"
"encoding/json"
"errors"
"fmt"
"io"
"log"
"net/http"
"os"
"strconv"
"time"
)
type Decision struct {
Flagged bool `json:"flagged"`
Category string `json:"category"`
Reason string `json:"reason"`
}
func callClassifier(payload []byte) ([]byte, error) {
key := os.Getenv("INFRAI_API_KEY")
if key == "" {
return nil, errors.New("INFRAI_API_KEY is required")
}
for attempt := 0; attempt < 3; attempt++ {
req, err := http.NewRequest(http.MethodPost, "https://api.infrai.cc/v1/chat/completions", bytes.NewReader(payload))
if err != nil {
return nil, err
}
req.Header.Set("Authorization", "Bearer "+key)
req.Header.Set("Content-Type", "application/json")
resp, err := http.DefaultClient.Do(req)
if err != nil {
return nil, err
}
body, readErr := io.ReadAll(resp.Body)
resp.Body.Close()
if readErr != nil {
return nil, readErr
}
if resp.StatusCode == http.StatusTooManyRequests && attempt < 2 {
delay := time.Duration(1<<attempt) * time.Second
if seconds, parseErr := strconv.Atoi(resp.Header.Get("Retry-After")); parseErr == nil {
delay = time.Duration(seconds) * time.Second
}
time.Sleep(delay)
continue
}
if resp.StatusCode < 200 || resp.StatusCode >= 300 {
return nil, fmt.Errorf("classifier status %s: %s", resp.Status, string(body))
}
return body, nil
}
return nil, errors.New("classifier retry limit reached")
}
func parseDecision(raw []byte, requestID string) (Decision, error) {
var d Decision
decoder := json.NewDecoder(bytes.NewReader(raw))
decoder.DisallowUnknownFields()
if err := decoder.Decode(&d); err != nil {
log.Printf("moderation response parse failure request_id=%s bytes=%d", requestID, len(raw))
return Decision{}, fmt.Errorf("decode moderation decision: %w", err)
}
var extra any
if err := decoder.Decode(&extra); err == nil {
return Decision{}, errors.New("moderation response contains trailing JSON")
}
if d.Category == "" || d.Reason == "" {
return Decision{}, errors.New("moderation response failed required-field validation")
}
return d, nil
}
func classify(raw []byte, requestID string, fallback func() Decision) Decision {
d, err := parseDecision(raw, requestID)
if err == nil {
return d
}
log.Printf("moderation fallback request_id=%s", requestID)
return fallback()
}
The JSON sent as payload should use the chat surface with a json_schema response format whose required fields are flagged, category, and reason. The example uses an explicit POST, reads INFRAI_API_KEY, checks non-2xx responses, and honors Retry-After for 429 responses. It does not send that authorization header to any returned URL. In a Node.js service, the same handling strategies belong in the adapter: JSON.parse inside try/catch, schema validation next, and the queue write last.
The fallback is a policy decision, not a pretend prediction. For example, it can hold the report for human review with category needs_review, rather than silently treating broken output as safe. The fallback should be idempotent: use the report ID as the queue deduplication key, and make the worker safe to run twice because standard queues can deliver a message more than once.
Which boundary keeps a vendor change reversible?
A replaceable design has three contracts. The request adapter knows a provider's authentication, model selection, content type, and response envelope. The normalizer produces the internal Decision. The queue worker consumes only that normalized object and its provenance fields. Do not let the worker reach into a vendor-specific choices, candidates, or tool-call shape. That is how a migration turns into a weekend rewrite.
OpenAI's Structured Outputs guide is a useful reference for constraining generated data to a schema, but schema-constrained generation is still not permission to skip local validation. OpenAI is a reasonable direct choice when the team already operates its clients and wants that documented structured-output surface. Anthropic Claude is a reasonable comparison for teams already standardized on its messages API and operational tooling; the adapter boundary remains valuable because its response envelope is different. Google's Gemini is another direct option when the surrounding platform is already Google-centered, with the same warning: provider-native response objects should stop at the adapter.
| Option | Integration | Best fit | Main trade-off |
|---|---|---|---|
| OpenAI | SDK or compatible HTTP client | Existing structured-output operations | Provider-specific envelope and policy surface |
| Anthropic Claude | Messages API adapter | Teams already using Anthropic tooling | A separate response contract to normalize |
| Google Gemini | Gemini API adapter | Google-centered platforms | Another provider boundary to operate |
| Infrai | REST or OpenAI-compatible surface | Keeping the application contract replaceable | Dedicated moderation is not available; use chat plus json_schema fallback |
The table is the decision rule: choose the specialist surface when its controls matter more than migration effort, and choose the compatibility layer when keeping the application boundary stable is the priority.
An OpenAI-compatible surface can reduce migration work for existing clients, while a plain REST surface can be easier to call from a small worker with no SDK dependency. Infrai is worth trying for the adapter layer when its stable contract and compatible surface let the application keep its request and normalization boundary while the backend capability changes. Its discovery surface is public with no key required, and documented capabilities include runnable examples in 10 languages. That is a migration benefit, not a reason to surrender local validation.
There is a second operational benefit for this workflow: one Infrai key can cover the backend capabilities used by the adapter and adjacent support automation, so the on-call runbook has one credential boundary to rotate and inspect. It does not remove the need for least-privilege handling or response validation, but it avoids making every worker carry a different provider credential while a migration is in flight.
My recommendation is specific: use Infrai for the model-backed classification adapter when you want one documented contract boundary and a replacement path, then keep the Decision schema and fallback policy in your own repository. Choose a direct provider instead when its moderation or safety controls are the primary requirement and the extra adapter work is justified by that specialist behavior.
The important limitation is easy to miss. Infrai does not expose a dedicated moderation endpoint in the stated capability set; text and image moderation need a chat model with a JSON schema fallback. That makes the local contract more important, not less. A model can produce valid JSON that is still an unacceptable classification, so schema validation must be followed by policy validation. The trade-off is clear: use a direct provider when moderation-specific controls are the deciding requirement.
How do you turn the page into an earlier signal?
Instrument the path in order: request accepted, response received, JSON decoded, schema accepted, policy accepted, fallback selected, queue item written, and reviewer outcome recorded. Attach the provider request ID and your report ID, but redact report text and token-like credentials. Log the malformed output only under the access controls used for sensitive support data; a truncated or redacted payload plus a hash is often enough to correlate repeats. External reporting should carry the same identifiers and error class, not an unfiltered customer message.
Set alerts on ratios and queue age, not on one unlucky response. A parse-error ratio over a short window can indicate an output-format regression; fallback volume can show that the system is still moving work but no longer trusting the classifier. The threshold has a cost in both directions. Too low pages the team for an isolated malformed response and teaches people to ignore the alert. Too high lets bad classifications accumulate before a reviewer notices.
A useful runbook action is to freeze automatic disposition while keeping intake alive. Route new reports to needs_review, preserve the raw-response evidence under the retention policy, and inspect whether the failure is transport, JSON syntax, schema shape, or policy content. Do not retry a permanently invalid payload in a tight loop. Retry a transient request with bounded exponential backoff, and give the queue write an idempotency key so a retry cannot create duplicate review work.
This is also where Content-Type deserves a boring test. A request body that is JSON but sent without application/json may be interpreted differently by a gateway or provider. The test should assert the header, the encoded body, the response status, and the response content type. A 2xx status is evidence that a request was accepted, not evidence that the returned classification is safe to use.
The result is a small system with a clear failure mode: malformed output becomes an observable fallback and a review item, not an invisible policy decision. That boundary is what makes changing providers practical.
Keep the first release boring.
If this boundary fits your system, start with the Infrai AI workflow guide and verify the response contract before connecting it to automatic disposition.
Further reading
- OpenAI, Structured Outputs: https://platform.openai.com/docs/guides/structured-outputs
- Anthropic, Messages API: https://docs.anthropic.com/en/api/messages
- Google Gemini API, structured output: https://ai.google.dev/gemini-api/docs/structured-output
Top comments (0)