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
- Song generation
- Music generation
- Singing generation
- Remix
- Extend song
- Extend music
- Lyrics
- Copyright / recognition
- Status polling
- Stem separation
- Not covered by compat
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 field | Resolves to | New field |
|---|---|---|
| prompt, lyrics, parameters.versions, parameters.gender | generate_song | prompt, lyrics, versions, gender |
| reference_url | similar_song | song_reference |
| melody_url | melody_to_song | melody |
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
styleOfMusic→prompt, lyrics, audioUrl→vocal_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_at→extend_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, duration→extend_seconds, side. Old styleOfMusic folds into prompt.
Lyrics
POST/v1/generate/lyrics→ write_lyrics
prompt→theme. 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:
similar_music— see Music Generationmidi_to_song— see Song Generationtranscribe— see Transcriptionsfx_gen— see Sound Effectsaudio_effect— see Audio Effect