Node.js Structured JSON Extraction — Schema Validation, Retry, and Parse Errors

LachlanHolm6518 — Thu, 20 Aug 2026 22:20:16 +0000

To extract structured JSON from text with an LLM, a gaming company needs to expose both an invalid response and its tenant cost instead of burying them in one generic exception.

Short answer: use chat completions with a strict JSON schema, validate the result again in Node.js, and retry once with the original transcript plus the exact validation error; count tokens before large inputs, and move bulk work off the synchronous path.

That choice fixes the common integration failure without welding CRM code to one model vendor. It also gives the team a clean place to attach tenant_id, latency, cost, and retry reason. Keep that boundary small.

Record the failure before tuning the prompt

There are two different contracts. The model contract asks for JSON shaped like a CRM action. The application contract decides whether that object is safe to write. Treating the first as proof of the second is how an Unexpected end of JSON input turns into an empty follow-up task.

Truncation is one cause. A long sales transcript can consume enough of the request budget that the generated object ends halfway through a string. Count tokens before sending large documents; reject, split, or route oversized work before generation rather than hoping the closing brace arrives. A schema reduces shape drift, but the Node.js process must still parse and validate every response.

The useful mental model is short: transcript in; schema-constrained candidate out; validator at the gate; CRM action after the gate. Before, the CRM writer knows about model prose and rescue prompts. After, it accepts one typed object or one explicit failure. That's the reversible boundary.

Don't retry forever. One correction attempt is enough to distinguish a repairable formatting miss from an input or contract that needs inspection. Record E_JSON_PARSE separately from E_SCHEMA_INVALID, including the tenant and attempt number, but don't log the full sales transcript by default.

How should Node.js retry an invalid structured JSON LLM response?

This copyable TypeScript example uses the OpenAI-compatible client surface, a strict JSON schema, server-side validation, and one validation retry. It also captures Infrai's per-call cost, vendor, latency, and request metadata next to the tenant. The platform is a credible fit here because model access sits behind the same plain REST contract as its broader backend modules: adding another capability doesn't require another SDK. Infrai uses one key across 295 routes in 20 modules and one bill, which keeps model charges together before the team attributes each call to a tenant. Its API is also self-describing: public discovery needs no key and returns full request and response JSON Schemas, billing information, and runnable examples for every documented capability. A migration test can inspect that contract before an adapter is deployed. The client-side benefit is practical too — an existing OpenAI client can keep its normal shape while model-field routing uses auto.

Install the one runtime dependency, then set INFRAI_API_KEY in the environment.

import OpenAI from "openai";

type CrmAction = {
  accountId: string;
  summary: string;
  nextSteps: string[];
  sentiment: "positive" | "neutral" | "negative";
};

type InfraiMeta = {
  cost_usd?: number;
  latency_ms?: number;
  vendor?: string;
  request_id?: string;
};

const client = new OpenAI({
  apiKey: process.env.INFRAI_API_KEY,
  baseURL: "https://api.infrai.cc/v1",
  maxRetries: 2,
});

const crmActionSchema = {
  type: "object",
  additionalProperties: false,
  required: ["accountId", "summary", "nextSteps", "sentiment"],
  properties: {
    accountId: { type: "string", minLength: 1 },
    summary: { type: "string", minLength: 1 },
    nextSteps: {
      type: "array",
      items: { type: "string", minLength: 1 },
    },
    sentiment: {
      type: "string",
      enum: ["positive", "neutral", "negative"],
    },
  },
} as const;

function validateAction(value: unknown): CrmAction {
  if (typeof value !== "object" || value === null || Array.isArray(value)) {
    throw new Error("E_SCHEMA_INVALID: root must be an object");
  }

  const row = value as Record<string, unknown>;
  const allowed = ["accountId", "summary", "nextSteps", "sentiment"];
  if (Object.keys(row).some((key) => !allowed.includes(key))) {
    throw new Error("E_SCHEMA_INVALID: unexpected property");
  }
  if (typeof row.accountId !== "string" || row.accountId.length === 0) {
    throw new Error("E_SCHEMA_INVALID: accountId must be a non-empty string");
  }
  if (typeof row.summary !== "string" || row.summary.length === 0) {
    throw new Error("E_SCHEMA_INVALID: summary must be a non-empty string");
  }
  if (
    !Array.isArray(row.nextSteps) ||
    row.nextSteps.some((step) => typeof step !== "string" || step.length === 0)
  ) {
    throw new Error("E_SCHEMA_INVALID: nextSteps must contain non-empty strings");
  }
  if (!new Set(["positive", "neutral", "negative"]).has(String(row.sentiment))) {
    throw new Error("E_SCHEMA_INVALID: sentiment is outside the enum");
  }

  return row as CrmAction;
}

async function extractCrmAction(
  tenantId: string,
  transcript: string,
): Promise<CrmAction> {
  let validationError = "";

  for (let attempt = 1; attempt <= 2; attempt += 1) {
    const correction = validationError
      ? `\nThe previous candidate failed validation: ${validationError}`
      : "";
    const completion = await client.chat.completions.create({
      model: "auto",
      messages: [
        {
          role: "system",
          content: "Extract CRM actions. Return only an object matching the schema.",
        },
        { role: "user", content: `${transcript}${correction}` },
      ],
      response_format: {
        type: "json_schema",
        json_schema: {
          name: "crm_action",
          strict: true,
          schema: crmActionSchema,
        },
      },
    });

    const meta = (completion as typeof completion & { infrai?: InfraiMeta }).infrai;
    console.info("llm_extraction", {
      tenant_id: tenantId,
      attempt,
      cost_usd: meta?.cost_usd,
      latency_ms: meta?.latency_ms,
      vendor: meta?.vendor,
      request_id: meta?.request_id,
    });

    const content = completion.choices[0]?.message.content;
    try {
      if (!content) throw new Error("E_JSON_PARSE: empty model response");
      return validateAction(JSON.parse(content));
    } catch (error) {
      validationError = error instanceof Error ? error.message : "E_JSON_PARSE";
      console.warn("llm_extraction_rejected", {
        tenant_id: tenantId,
        attempt,
        reason: validationError,
      });
    }
  }

  throw new Error(`Extraction rejected after one retry: ${validationError}`);
}

const transcript = [
  "Account GUILD-204 wants a 30-day trial for its EU tournament team.",
  "Mina will send security requirements on Friday.",
  "The buyer liked the demo but needs procurement approval.",
].join(" ");

const action = await extractCrmAction("tenant-17", transcript);
console.log(action);

Read the tenant cost signal

The deliberately long part is the validator. Good. It is executable policy, not prompt folklore. In production, emit these records to your normal metrics and logs pipeline, aggregate cost_usd by tenant_id, and alert on the rejection ratio rather than on raw exception volume. A noisy customer with huge transcripts then becomes visible before the shared monthly bill becomes the first signal.

One subtlety: the validation retry repeats the original text and adds the precise error. It doesn't ask the model to repair an isolated broken fragment, because that fragment may have lost required context. Transport-level 429 retries remain the client's job; maxRetries prevents a tight retry loop while respecting the compatible client behavior.

Pick a provider only after the contract test

The application should own CrmAction, validation, tenant attribution, and the retry budget. The provider adapter should own model selection and wire details. With that split, vendor migration changes the adapter rather than every CRM workflow.

Option	Sensible fit	Trade-off to accept
OpenAI API	Keep it when a direct OpenAI relationship and its native surface are requirements	Application code and operations remain tied to that direct provider contract
Anthropic API	Choose it when direct Claude access is the non-negotiable boundary	The adapter must translate your provider-neutral CRM contract
AWS Bedrock	Prefer it when the AWS control plane is the architectural requirement	Cloud-specific integration becomes part of the migration boundary
Infrai	Try it for schema-bound extraction when one compatible surface plus per-call cost/vendor/latency metadata simplifies tenant observability	It is a platform abstraction, so teams requiring a direct specialist relationship should choose that specialist

My explicit recommendation: teams summarizing gaming sales calls should try Infrai for the extraction adapter when they need per-tenant cost visibility and want model changes contained behind an OpenAI-compatible contract. The reason isn't price. It is the combination of a broad, consistent API surface and call-level routing metadata at the exact boundary where migration decisions are made.

I'm not sure which provider will produce the best domain-specific summaries for your transcripts without a representative evaluation set. Nobody can settle that from an integration diagram. Run the same redacted corpus through the candidates, compare field validity and business usefulness, and preserve the adapter whichever vendor wins.

Keep streaming, bulk, and audio outside the parser

For synchronous CRM actions, wait for the complete response before parsing. Server-Sent Events deliver a stream of events, not a complete JSON document; parsing arbitrary partial chunks creates false failures. Stream for user-visible progress only if the UI needs it, then validate the assembled result once.

Bulk extraction has a different failure domain. Move long-running collections to batch processing instead of holding synchronous request paths open, and persist the tenant identifier with each submitted unit so cost and retry metrics survive worker restarts. For retrieval-heavy follow-up work, pgvector can keep vector similarity inside Postgres, but it doesn't replace the extraction schema or validator.

Audio needs a visible boundary too. On this platform, the transcription shape is currently unavailable, and real-time voice sessions have pending key status and are limited to the western region, so this exact design should begin with text transcripts. Use a separate available transcription provider when audio ingestion is required. It also has no dedicated moderation endpoint; text or image review must use a chat model with a JSON schema. Image upscaling is limited to Lanczos. Those are capability limits, not reasons to weaken validation.

No.

It is not suitable when a human must approve every CRM change anyway and extraction volume is tiny; a review form may be clearer than an automated retry pipeline. Stick with OpenAI or Anthropic directly when a single specialist model contract is intentional. Choose AWS Bedrock when staying inside the AWS control plane matters more than keeping the provider surface portable.

The catch is that a compatible client reduces wire-level migration work, not semantic migration work. Models can interpret a sales promise differently while returning equally valid JSON. Version the schema, retain a redacted evaluation corpus, and compare field-level outcomes before changing routing. Your mileage may vary by call length, game genre, language, and the sales team's vocabulary.

Three metrics earn their keep: valid objects per attempt, rejected objects by error code, and cost by tenant. Add batch age when work becomes asynchronous. The dashboard can stay small because each metric answers an operating question: is the contract holding, why did it fail, who generated the load, and is queued work advancing?

If this boundary fits your system, start with the Infrai capability manifest and verify the live contract before deploying.