aisplice

By capability

Music

Music runs as a task: submit a prompt, then check back or get a callback. Start with the prompt alone.

#1. Pick a model

suno$0.07 / requestLimits and status

1 models online for this. Switching changes the code below.

#2. Copy the request

Replace YOUR_API_KEY with your key, then run it. Options shown are the ones this model accepts.

POSThttps://www.aisplice.store/v1/music/generationsBearer API keyAsync task

OptionsOnly options published for this model are shown.

# Requires curl and jq
API_KEY="${API_KEY:-YOUR_API_KEY}"

# 1. Submit once
SUBMITTED=$(curl --fail-with-body -sS https://www.aisplice.store/v1/music/generations \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: model-docs-$(date +%s)-$$" \\
  -d '{
  "model": "Suno",
  "prompt": "An uplifting electronic track for a product launch",
  "operation": "music",
  "version": "v6",
  "custom": false,
  "instrumental": false
}')
TASK_ID=$(printf '%s' "$SUBMITTED" | jq -r '.task_id // .id // empty')
if [ -z "$TASK_ID" ]; then
  printf '%s\n' "$SUBMITTED" >&2
  exit 1
fi
echo "task_id=$TASK_ID"

# 2. Poll until terminal
while true; do
  STATUS_JSON=$(curl --fail-with-body -sS \
    "https://www.aisplice.store/v1/music/tasks/$TASK_ID" \
    -H "Authorization: Bearer $API_KEY")
  STATUS=$(printf '%s' "$STATUS_JSON" | jq -r '.status // empty' | tr '[:upper:]' '[:lower:]')
  echo "status=$STATUS"
  case "$STATUS" in
    completed|succeeded|success) break ;;
    failed|failure|cancelled|canceled)
      printf '%s\n' "$STATUS_JSON" | jq .
      exit 1
      ;;
  esac
  sleep 3
done

# 3. Fetch the final result
curl --fail-with-body -sS \
  "https://www.aisplice.store/v1/music/tasks/$TASK_ID/content" \
  -H "Authorization: Bearer $API_KEY" | jq .

All parameters

Every field this model accepts, with the allowed values.

prompt
stringoptional

Instruction describing the desired result.

Response lifecycle

Task status, terminal states, and result response examples.

Submit
{
  "id": "task_xxx",
  "task_id": "task_xxx",
  "object": "music.task",
  "model": "Suno",
  "status": "queued"
}

Waiting

queued · submitted · in_progress · processing

Success

completed · succeeded · success

Failure

failed · failure · cancelled · canceled

Every field: /v1/music in the API reference →

#3. Get the result

The submit call answers with a task_id at once. Check the task every few seconds until status is completed, or pass webhook_url and we call you when it is done.

GET https://www.aisplice.store/v1/music/tasks/{task_id}

GET https://www.aisplice.store/v1/music/tasks/{task_id}/content

Charged only when it succeeds

A failed or cancelled task is refunded automatically. The request log shows each task’s final cost.

Status values and polling →Get a callback instead of checking →

#When it goes wrong

  • 400 with a field name: that option is not accepted by this model; use the values listed in step 2.
  • Content refused by the model: rephrase the prompt; refused requests are not charged.
  • 402: the balance cannot cover this request; top up in Wallet, then retry.
  • 429: slow down and retry after the Retry-After seconds.
  • 503 model_not_found: the model name is wrong or the model is offline; pick one from step 1.

Look up any other error →

Building it into your productWhich options to show your users first, and which to leave for later.
Which options to show your users firstStart with the prompt and one price knob; add the rest once the basic flow works.+

Creative intent

Fields like prompt belong in the UI because the user directly understands the outcome they change.

Cost multiplier

Fields like duration, resolution, size, and count should be introduced only when pricing is already explainable.

Mode switch

Fields like image, mask, or continuation IDs change the workflow itself and should appear only in dedicated modes.

System plumbing

Fields like webhook_secret are for integrators, not for everyday creators, so keep them out of default UI.

  • prompt
    Expose when
    Always. It is the minimum viable music input.
    Recommended default
    Required in UI.
    Why it matters
    It carries the theme, genre, and emotional direction.
  • instrumental / make_instrumental
    Expose when
    Expose when the product clearly distinguishes vocals vs instrumental output.
    Recommended default
    Keep server-side unless users choose between vocal and instrumental tracks.
    Why it matters
    It changes the output type and should map to a clear business choice.
  • title / tags
    Expose when
    Expose only after prompt-only generation is already understood by users.
    Recommended default
    Optional advanced fields.
    Why it matters
    They help style control, but they should not block first success.
  • version / mv
    Expose when
    Expose only if users must choose a model family or generation mode.
    Recommended default
    Pin one recommended version on the server.
    Why it matters
    It increases decision fatigue and usually belongs to operator controls.
  • continue_clip_id / continue_at
    Expose when
    Expose only in continuation or extension workflows.
    Recommended default
    Hide in standard creation flows.
    Why it matters
    These are expert controls and confuse first-time users if shown too early.
recommended-rollout.txt
Phase 1
- prompt
- one size or one duration default
- submit -> poll -> content

Phase 2
- one quality or resolution selector
- clear pricing hint

Phase 3
- advanced controls such as reference media, continuation, webhook, or vendor-specific tuning

Keep one source of truth for results

When a task finishes, normalize your app around the platform URL returned by /content. That keeps upstream vendor details hidden and makes historical playback stable.

Still stuck?

Send us the request ID or the error message and we will look into it.