Edited a script? Reuse unchanged TTS takes with verify-spine

When you edit one sentence of a script that already has TTS takes, you do not have to regenerate everything. Sume's POST /v1/tts-1.0/source/verify-spine is a read-only check that tells you whether the takes you picked still cover the accepted script, in order, so you regenerate only the sentences that changed.

The route is in the OpenAPI reference as "Verify complete accepted TTS spine coverage without generation", and the same check is exposed as the tts_source_verify_spine tool in the MCP tools list. The behavior below is from Sume's source-bound TTS contract in the repository. It is built for Agent threads and Format runs that work from an accepted script, not for a bare API key with free text.

What is a source-bound TTS take?

TTS 1.0 and the TTS Router accept exactly one text input: transcript (literal text, 1 to 20,000 characters) or transcript_source, which names a script_revision_id and a list of sentence_ids. You discover both with GET /v1/tts-1.0/source inside the thread. The server resolves the sentence text itself, so you never copy script bytes, and the IDs must be unique, contiguous and in source order.

A job made from a source reference gets a server-owned transcript_receipt: job id, revision, sentence IDs, a canonicalization version and the SHA-256 of the submitted text. That receipt proves what text the job was asked to speak. It does not prove the pronunciation, so listen to the audio separately.

What does verify-spine check?

The request body has a script_revision_id and up to 1,000 selected_jobs, each with a job_id and optional sentence_ids. The server checks that the successful jobs together give complete source coverage of the pinned revision, in order, with no writes, no provider calls and no regeneration. Jobs from before receipts existed must name sentence IDs, and the server compares their stored text to the script after canonicalization.

If the text matches exactly, an old take can be adopted into the current revision without regenerating. If it does not match, it cannot be adopted. A missing receipt on its own never triggers automatic regeneration.

What does the call look like?

A request names the revision and the jobs you want to count. Sentence IDs are optional for jobs that carry a receipt for the revision, and required for older jobs.

curl -X POST https://api.sume.com/v1/tts-1.0/source/verify-spine \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "script_revision_id": "rev_current",
    "selected_jobs": [
      { "job_id": "job_intro" },
      { "job_id": "job_old_middle", "sentence_ids": ["s3", "s4"] },
      { "job_id": "job_outro" }
    ]
  }'

What is the money-saving workflow after an edit?

Speech is billed per character, at $0.0475 per 1,000 characters at the public rate, so reusing a take saves exactly what regenerating it would cost. For a 12,000-character script, one changed 300-character sentence is about a cent to redo; the other takes cost nothing again.

• Edit the script and accept the new revision in your thread.
• Run verify-spine with all the takes you made, naming sentence IDs for older ones.
• Regenerate only the sentences it reports as not covered.
• Run verify-spine again with the new job ids, and then join the takes with timeline audio.

What does it not do?

It does not listen to audio, judge pronunciation or check loudness, and it does not generate anything. It cannot pull a revision from another thread or workspace: a stale, missing or mismatched revision fails closed. And a bare key with literal text has no revision to verify, so for that path keep your own record of which job spoke which sentence.

Treat it as the bookkeeping half of a retake, and pair it with a listen-through of the joined audio before you ship.