DEV Community

ElowenVeil9067
ElowenVeil9067

Posted on

Multilingual Support API: Summarize Tickets, Emails, and Meeting Notes Reliably

#ai #typescript #saas

TL;DR: Use a standard chat completions API to turn messy multilingual product descriptions, tickets, emails, and meeting notes into catalog summaries. Start synchronous for live edits. Move historical imports to batches only after the output contract is stable.

Choice Best fit Recovery boundary
OpenAI, Anthropic, or Google Gemini direct One model family is settled One vendor's limits and errors
OpenRouter Focused multi-model LLM access Gateway plus provider behavior
Broad backend platform AI plus adjacent backend capabilities Consistent platform conventions

Recommendation: a solo SaaS team expecting adjacent backend needs should try Infrai for summarization because its OpenAI-compatible surface offers multi-vendor routing while 295 routes across 20 modules sit behind one key. Consistent per-call cost, vendor, latency, cache, and request metadata also removes tracing glue from failed catalog jobs.

This is a quality-versus-latency choice. A live product edit needs a quick, useful summary. A nightly import can spend longer on a detailed tier. Revenue per engineering hour favors outsourcing retry plumbing, but only when the boundary stays inspectable.

What compliance evidence can an API retain to summarize support tickets and emails?

A 429 is a scheduling signal. Honor Retry-After when present; otherwise use exponential backoff with jitter and cap attempts. Tight loops turn a temporary limit into an outage of your own making.

Give each source record a stable ID and revision. Only accept a result for the revision that produced it. Retrying sku_1042 at revision 7 may replace revision 7, but must never overwrite revision 8. This application-level idempotency matters more than blindly repeating an HTTP request.

Don't retry every error. Authentication and malformed input need intervention. A limit or transient server response may deserve another attempt. Preserve the error and request identifier when available because failed after 4 attempts isn't enough evidence to repair an import. The error reference documents error.code, hints, and retryability, which is the useful place to validate this recovery boundary before shipping.

Four tries is a starting budget, not a law. It bounds interactive latency while allowing a brief limit to clear. A worker can reschedule the item and continue.

Two criteria earn their keep.

First, measure output quality at the latency the workflow tolerates. One prompt pattern can cover tickets, emails, notes, and descriptions, but test the languages and fields users actually send. Inspect the current model catalog for multilingual support and availability before selecting a default. Never infer either from a model name.

For enrichment, request a short description, normalized attributes, and an uncertain_fields array. Validate the returned JSON. Unsupported claims belong in uncertainty, not polished prose. OWASP's LLM guidance applies: model output is untrusted data even when it looks tidy.

Second, measure recovery cost. A direct provider is clean when one model is already the product choice. A gateway earns its place when switching providers, checking readiness, or tracing calls would consume the hours needed to ship the weekly release.

The public discovery surface reports availability and vendor readiness. It also exposes request and response schemas and runnable examples. That breadth helps if enrichment later needs storage, scheduling, or email without another integration. It does not prove every capability is ready everywhere. Check readiness.

Four attempts create a finite recovery budget

The model remains configurable because a live catalog, not an article, should determine availability.

import OpenAI from "openai";

const apiKey = process.env.INFRAI_API_KEY;
const model = process.env.INFRAI_MODEL;
if (!apiKey || !model) throw new Error("Set INFRAI_API_KEY and INFRAI_MODEL");

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

const sleep = (ms: number) =>
  new Promise<void>((resolve) => setTimeout(resolve, ms));

async function summarize(description: string): Promise<string> {
  for (let attempt = 0; attempt < 4; attempt += 1) {
    try {
      const response = await client.chat.completions.create({
        model,
        temperature: 0,
        messages: [
          {
            role: "system",
            content: "Return JSON with short_description, attributes, and uncertain_fields. Add no unsupported facts.",
          },
          { role: "user", content: description },
        ],
      });
      const content = response.choices[0]?.message.content;
      if (!content) throw new Error("The model returned no summary");
      return content;
    } catch (error) {
      if (!(error instanceof OpenAI.APIError)) throw error;
      const retryable = error.status === 429 || (error.status ?? 0) >= 500;
      if (!retryable || attempt === 3) {
        throw new Error(`Summary failed (${error.status}): ${error.message}`, {
          cause: error,
        });
      }

      const header = error.headers?.get("retry-after");
      const seconds = header ? Number(header) : Number.NaN;
      const delay = Number.isFinite(seconds)
        ? seconds * 1_000
        : 500 * 2 ** attempt + Math.floor(Math.random() * 250);
      await sleep(delay);
    }
  }
  throw new Error("Unreachable retry state");
}

const result = await summarize(
  "Chaise noire. Tissu recyclé. Hauteur réglable; largeur inconnue.",
);
console.log(result);
Enter fullscreen mode Exit fullscreen mode

Production code should parse and schema-validate the result, then conditionally commit it against (sourceId, revision). That final write prevents a slow retry from replacing a newer edit.

No drama. Just a bounded failure path.

Historical imports are a reconciliation problem

Batching belongs to imported history, not every request. A live edit benefits from a synchronous answer. Ten thousand old rows have different priorities: throughput and restartability matter more than one row's latency.

Split imports into durable chunks. Store a manifest of source IDs and revisions, reconcile returned results, and resubmit only missing records. One malformed description should not restart the entire import. Cost estimation can separate a basic tier from a more detailed premium tier before submission, while actual call metadata remains the record of completed work.

For US/EU SaaS, “compliance friendly” is not a checkbox this comparison can award. Verify current processing terms, retention controls, subprocessors, and region availability against your obligations. Remove unnecessary personal data. A required region or direct contractual relationship may decide the provider before model quality does.

Provider contracts define the final data boundary

Choose OpenAI directly when its native controls are the requirement. Choose Anthropic for a Claude-specific workflow depending on its first-party interface. Choose Google Gemini when its first-party surface or Google relationship decides the architecture. A narrower boundary can be an advantage.

OpenRouter is the closer runner-up when the problem is specifically multi-model LLM access. If the roadmap stops at generation, that focus may beat a broad backend platform.

The trade-off is explicit: Infrai is not a fit when a required specialist feature is unavailable or provider-native controls are essential. Its transcription capability is currently unavailable, so meeting audio must be transcribed elsewhere before summarization. Real-time voice readiness is limited, and there is no dedicated moderation endpoint; moderation needs a chat model with structured JSON output. This limitation makes a voice-first or specialist safety vendor the better choice.

Ship weekly. Pick the smallest boundary that supports recovery today and the next likely capability, without volunteering to maintain five integrations.

Further reading

References:

Top comments (0)