Enterprise API

Compat Routes

If you integrated against the old Enterprise API, most of your existing URLs and field names keep working. The gateway resolves the right tool for you — you never need to look up a tool_id.

How it works

Compat routes live at the same bare paths the old API used (no /v1 prefix, except where the old path already had one, e.g. /v1/generate/lyrics). They take the same Authorization: Bearer sksoundverse_... header as every other endpoint, and the same Idempotency-Key header for safe retries.

Every create route returns 201 with a uniform body, regardless of which old field name (messageId, message_id, etc.) the capability historically used:

{"job_id": "...", "status": "queued"}

job_id is the same underlying id the native API calls id — you can poll it with either this page’s status routes or the native GET /v1/generations/{job_id}, and stream it with GET /v1/generations/{job_id}/stream (compat has no streaming route of its own).

No synchronous variant

Unlike the old /sync endpoints, there is no blocking compat route — the new gateway has no internal blocking primitive. Every compat create call returns a job_id immediately; poll or stream for the result.

Song generation

POST/v{5,6,7}/generate/song

Maps to generate_song, similar_song, or melody_to_song depending on which reference field you send:

Old fieldResolves toNew field
prompt, lyrics, parameters.versions, parameters.gendergenerate_songprompt, lyrics, versions, gender
reference_urlsimilar_songsong_reference
melody_urlmelody_to_songmelody

vocal_id is also accepted for prompt-based and reference-song generation. It must be a saved Soundverse ID from Voice Cloning(for example, sv_voice_...), not a provider voice ID. It is not supported with melody_url.

vocal_url / instrumental_url alone (no reference_url or melody_url) return 400 UNSUPPORTED_REFERENCE — there is no new-side equivalent. midi_to_song has no compat route at all (the old request body never had a MIDI field to map from) — use the native Song Generation page for that.

Music generation

POST/v{5,6,7}/generate/music→ generate_music

prompt, parameters.versions. The old style field has no equivalent on the new tool, so it’s folded into prompt text rather than dropped.

similar_music has no compat route — see Music Generation for the native path.

Singing generation

POST/v{5,6,7}/generate/singing→ generate_singing

styleOfMusicprompt, lyrics, audioUrlvocal_reference. A completed Voice Cloning task’s vocal_id can also be passed through to sing in that saved voice.

This is a new URL, not a literal recreation — the old singing endpoint was version-less (/v2/generate/ai-singing-gen), predating the v5/v6/v7 family. It’s offered at/v{5,6,7}/generate/singing for consistency with every other capability here.

Remix

POST/v{5,6,7}/generate/remix→ remix_song

song_reference_url (required)→song, prompt, lyrics. Missing song_reference_url returns 400 {"error": "MISSING_FIELD"}. The old free-form parameters object has no equivalent and is dropped.

Extend song

POST/v{5,6,7}/extend/song→ extend_song

audio_url (required)→song, lyrics, extend_atextend_at_ms. Missing audio_url returns 400 {"error": "MISSING_FIELD"}. The old prompt field has no equivalent on ExtendSongIn and is dropped, not folded.

Extend music

POST/v5/extend/music→ extend_music (v5 only)

POST/v1/generate/extendalias for the same route

audio_url (required)→music, prompt, durationextend_seconds, side. Old styleOfMusic folds into prompt.

Lyrics

POST/v1/generate/lyrics→ write_lyrics

prompttheme. Every other field (style/mood/language/structure/rhyme) is left unset, taking the tool’s own defaults.

Copyright / recognition

GET/v5/recognize?audio_url=...→ copyright

audio_url is a required query param; missing it returns 400 {"error": "MISSING_FIELD"}.

Behavior change from the old API

The old /v5/recognize was synchronous — it returned the match result directly. This route returns a job_id like every other compat route; poll or stream for the result. The new gateway has no synchronous primitive to replicate the old behavior with.

Status polling

GET/v5/status?job_id=...

GET/v6/status?job_id=...

GET/v7/status?job_id=...

One shared implementation across all three — behavior doesn’t vary by version.

{ "job_id": "...", "status": "queued" | "processing" | "completed" | "failed", "error_message": "", "output": { ... } // present once completed; the tool's raw output, verbatim }

output is not reshaped into the old capability-flavored field names (audio_data, album_art, song_name, etc.) the way the old /v5/status response was — this is deliberate, not a bug: guessing renamed fields per capability risks silently wrong data. There is no progress field on this route either — use GET /v1/generations/{id}/stream for live progress.

Stem separation

POST/v1/generate/stem-separation/all-stems→ 12stem

POST/v1/generate/stem-separation/vocals→ 2stem

POST/v1/generate/stem-separation/instruments→ 2stem

POST/v1/generate/stem-separation/six-stem→ v5

vocals and instruments resolve to the same 2stem tool and the same job — it always produces both a vocals and an instrumental role-tagged asset, so pick whichever one you need from the response. six-stem is a new route, not a recreation of an old URL — the old API never had a 6-stem endpoint.

All four take the old StemRequest body shape, {"audioUrl": "...", "audioId": "..."} — only audioUrl maps to the new tool’s audio field; audioId has no equivalent and is dropped. Missing audioUrl returns 400 {"error": "MISSING_FIELD"}.

Not covered by any compat route

These capabilities are native-only — there is no old-style URL for them: