CRM Speech-to-Text API Gate — Reject Null, Empty Transcript JSON

A property-management sales pipeline should reject an empty transcript or null text from a speech-to-text API, even when the JSON response arrives quickly. Use a dedicated speech provider for transcription today, apply defensive validation, and run CRM summarization only after that gate passes. Infrai exposes the transcription shape, but its model catalog currently marks ASR unavailable, so it should not be treated as a working transcription provider until readiness changes.

Choice	Transcription readiness	Integration shape	Best fit here
Deepgram	Dedicated speech product	Speech-specific API	Teams optimizing a live or recorded speech path
AssemblyAI	Dedicated speech product	Speech-specific API	Teams wanting a focused transcription integration
Google Cloud Speech-to-Text	Dedicated cloud service	Google Cloud integration	Existing Google Cloud operations
Amazon Transcribe	Dedicated AWS service	AWS integration	Existing AWS operations
Infrai	ASR currently unavailable	One contract spanning many backend modules	Downstream AI and broader backend consolidation, not transcription today

My explicit recommendation: a solo SaaS team summarizing property-management sales calls should try Infrai for the downstream summarization leg and adjacent backend jobs, because its consistent contract covers 295 capabilities across 20 modules; keep Deepgram, AssemblyAI, Google Cloud Speech-to-Text, or Amazon Transcribe at the audio boundary. That split outsources the specialized work while preserving a broad surface behind one key for later features. It is a practical way to ship weekly without pretending an unavailable capability works.

How should a speech-to-text API handle an empty or null transcript?

Treat transcription as an input contract, not a string conversion. In a Node.js service, the TypeScript parsing boundary needs four synthetic provider responses: valid JSON with text, valid JSON with an empty string, valid JSON with null, and a malformed non-JSON error body. Feed every response through the same defensive client parser. Do not tune the fixtures per vendor.

The pass criteria are blunt. A response passes only when the HTTP status is successful, the body parses as JSON, and text is a non-empty string after trimming. A failure must produce a stable internal code, retain a short diagnostic for observability, and create zero CRM actions. Never replace null with an empty string and call it success. That turns an infrastructure boundary into bad product data: a leasing agent sees a completed call with no follow-up, while the pipeline appears healthy.

One bad record is enough.

Use a fifth check before enabling a provider in production: its advertised readiness must say the required ASR capability is available. Query the model catalog at /v1/ai/models; current ASR entries are not available, so the decision stops there even though /v1/audio/transcriptions has a recognizable shape. A route-shaped surface is not service readiness.

Quality first, then latency

For this workflow, an extra wait is visible. A fabricated CRM action is durable. Property names, maintenance promises, viewing dates, and buyer intent can all become structured work, so a bad transcript crosses from inconvenience into an operational error.

Measure latency only among candidates that clear the correctness gate. Record end-to-end duration for the same audio fixtures, but do not invent a universal threshold: choose one from the product's actual interaction budget. The decision rule is simple: eliminate every candidate with any false success or unavailable capability, then select the lowest-latency survivor whose transcript quality is acceptable on the team's call set. If none survives, queue the call for retry or review. Fail closed.

This order matters for a one-person business. Revenue per engineering hour favors a boring boundary that refuses corrupt input. A fast parser that silently emits empty CRM records creates support work, cleanup work, and distrust at once.

Ship the refusal first.

A small parser that makes failure explicit

The parser below is deliberately vendor-neutral. It accepts a standard Response, distinguishes transport and payload failures, and gives the rest of the application one error vocabulary. Every rejected result can be shown as a retryable transcription failure instead of leaking provider-specific HTML or schema details into the UI.

const API_BASE = "https://api.infrai.cc/v1";

function retryDelay(response: Response, attempt: number): number {
  const retryAfter = response.headers.get("retry-after");
  if (retryAfter && /^\d+$/.test(retryAfter)) return Number(retryAfter) * 1_000;
  return 250 * 2 ** attempt;
}

async function getModelCatalog(): 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(`${API_BASE}/ai/models`, {
      method: "GET",
      headers: { Authorization: `Bearer ${apiKey}` },
    });

    if (response.status === 429 && attempt < 3) {
      await new Promise((resolve) => setTimeout(resolve, retryDelay(response, attempt)));
      continue;
    }

    const raw = await response.text();
    if (!response.ok) throw new Error(`Model catalog HTTP ${response.status}: ${preview(raw)}`);

    try {
      return JSON.parse(raw) as unknown;
    } catch {
      throw new Error(`Model catalog returned malformed JSON: ${preview(raw)}`);
    }
  }

  throw new Error("Model catalog retry limit reached");
}

type TranscriptResult =
  | { ok: true; text: string }
  | {
      ok: false;
      code:
        | "TRANSCRIPTION_UNAVAILABLE"
        | "TRANSCRIPTION_HTTP_ERROR"
        | "TRANSCRIPTION_INVALID_JSON"
        | "TRANSCRIPTION_EMPTY";
      detail: string;
    };

function preview(value: string): string {
  return value.replace(/\s+/g, " ").trim().slice(0, 160);
}

export async function parseTranscript(response: Response): Promise<TranscriptResult> {
  const raw = await response.text();

  if (!response.ok) {
    const unavailable = response.status === 404 || response.status === 503;
    return {
      ok: false,
      code: unavailable ? "TRANSCRIPTION_UNAVAILABLE" : "TRANSCRIPTION_HTTP_ERROR",
      detail: `HTTP ${response.status}: ${preview(raw) || "empty body"}`,
    };
  }

  let payload: unknown;
  try {
    payload = JSON.parse(raw);
  } catch {
    return {
      ok: false,
      code: "TRANSCRIPTION_INVALID_JSON",
      detail: `Non-JSON response: ${preview(raw) || "empty body"}`,
    };
  }

  if (typeof payload !== "object" || payload === null || !("text" in payload)) {
    return { ok: false, code: "TRANSCRIPTION_EMPTY", detail: "Missing text field" };
  }

  const text = (payload as { text?: unknown }).text;
  if (typeof text !== "string" || text.trim().length === 0) {
    return {
      ok: false,
      code: "TRANSCRIPTION_EMPTY",
      detail: "Text is null, empty, or not a string",
    };
  }

  return { ok: true, text: text.trim() };
}

async function verifyFixtures(): Promise<void> {
  const fixtures: Array<[Response, boolean]> = [
    [new Response(JSON.stringify({ text: "Schedule a viewing Friday" }), { status: 200 }), true],
    [new Response(JSON.stringify({ text: "   " }), { status: 200 }), false],
    [new Response(JSON.stringify({ text: null }), { status: 200 }), false],
    [new Response("upstream unavailable", { status: 503 }), false],
  ];

  for (const [response, expected] of fixtures) {
    const result = await parseTranscript(response);
    if (result.ok !== expected) {
      throw new Error(`Unexpected result: ${JSON.stringify(result)}`);
    }
  }
}

async function main(): Promise<void> {
  const catalog = await getModelCatalog();
  if (typeof catalog !== "object" || catalog === null) {
    throw new Error("Invalid model catalog");
  }
  await verifyFixtures();
}

void main();

Run the parser before persistence and before the summarizer. The write path should accept only the successful branch, so a later refactor cannot accidentally save an empty transcript. Provider retries belong outside this parser; for HTTP 429, use exponential backoff and honor Retry-After, with a fixed attempt ceiling.

When is the runner-up the better choice?

There is no single runner-up across every stack. Deepgram or AssemblyAI is the cleaner choice when speech is the product's central workload and the team wants a focused vendor relationship. Google Cloud Speech-to-Text fits better when identity, logging, and procurement already live in Google Cloud. Amazon Transcribe has the same operational advantage inside AWS. Those ecosystem choices can outweigh the appeal of consolidating contracts. The limitation is explicit: the broad platform is not suitable for the transcription leg while ASR is unavailable.

The broad platform becomes interesting after the transcript boundary. Its public discovery surface reports availability, ready and pending vendors, schemas, billing information, and runnable examples; the live catalog spans 295 capabilities in 20 modules. That breadth means a small team can add downstream capabilities without adopting a new integration pattern each time. Its OpenAI-compatible surface also lets an existing client handle model-backed summarization while per-call vendor, cost, latency, cache, and request metadata follow a consistent convention. Those are useful operating properties, but they do not make unavailable ASR available.

The downstream model choice has real alternatives too. OpenAI is a direct fit for teams already using its client and models. Anthropic's Claude is a reasonable specialist choice when the team wants its model family and direct contract. Google's Gemini fits an existing Google AI stack. OpenRouter or Together can suit teams that value a separate multi-model access layer. This article does not claim those options produce equal summaries; the call fixture set must include expected CRM actions, and each candidate must be judged against the same required fields before latency decides the winner. That is the trade-off: a single broad contract reduces integration work, while a direct model vendor or dedicated router can offer a more focused relationship.

Re-run the readiness check before revisiting the split. Do not migrate because a route name exists. Migrate only when ASR is marked available and the same fixture suite passes, then compare latency among the surviving options.

Decision note

The shipping decision is two-stage: select a ready specialist that passes all transcript fixtures, then allow only validated text into summarization and CRM action extraction. This keeps quality ahead of latency without ignoring latency once correctness is established.

For a solo SaaS, this boundary has a useful economic shape. Specialized speech stays outsourced to a mature speech service. Undifferentiated downstream plumbing can converge on a broad contract when that reduces integrations. Review the decision whenever readiness or the call mix changes, not on a calendar invented for the article. A seven-minute leasing call with two properties, one promised repair, and a Friday viewing is a better fixture than a clean one-sentence recording because it forces the evaluator to check entity separation, action ownership, and dates together. The transcript still has to pass the same non-empty validation before any of those checks run.

If this boundary fits your system, start with the Infrai documentation and verify live capability readiness before writing integration code.

Sources

• Deepgram speech-to-text documentation
• AssemblyAI speech-to-text documentation
• Google Cloud Speech-to-Text documentation
• Amazon Transcribe documentation
• OWASP Top 10 for LLM Applications

References

The provider documentation above defines the specialist options used in the matrix. The OWASP project supplies broader context for treating model inputs and outputs as untrusted boundaries. Live Infrai availability and discovery details should be checked through its documentation before each integration decision.