Skip to main content
Every Soundpiece endpoint works the same way: you submit a request, wait for it to finish, then download the result (see Async operations). The reference client is that loop written once, carefully, in a single file you copy into your project. It is short enough to read in a few minutes, and the rest of these docs use it. It takes care of the details that are easy to get wrong:
  • your API key comes from the SOUNDPIECE_API_KEY environment variable, never from your code;
  • every request has a timeout;
  • network errors, 429 and 5xx responses are retried, waiting as long as the Retry-After header asks;
  • a retried submit reuses its idempotency key, so a retry never creates the work twice;
  • waiting uses long polling (wait=true) and gives up after a deadline;
  • downloads are streamed to disk, not held in memory.

Get the file

  1. Set your API key in the environment your program runs in:
  2. Save the file for your language next to your code:
    • Python: save it as soundpiece.py, then run pip install requests.
    • JavaScript: save it as soundpiece.mjs. It needs Node.js 18 or later and nothing else.

What each function does

  • run(endpoint, body) submits body to endpoint, waits until the work is ready, and returns the finished result: the object under the response’s single key, such as the song object from create.new_song. It raises a SoundpieceError if the operation fails, and gives up after timeout seconds (10 minutes unless you pass another value).
  • download(url, path) saves the audio at one of a result’s signed URLs to a file, streaming it to disk as it arrives.
  • send(method, endpoint, ...) makes one API call with your key and a 30-second timeout. It retries network errors, 429 and 5xx up to five attempts, waiting Retry-After seconds when the response gives a wait, and 1, 2, 4, 8 or 16 seconds when it is missing or 0. run uses it; you only call it yourself for something run doesn’t do, such as polling an operation you submitted earlier.
  • SoundpieceError is what you get when the API rejects a request (any other 4xx; the message carries the response’s detail), when it keeps failing after every retry, or when an operation finishes as failed (the message carries its error.code and error.message).

Using it

Endpoints that make several files return them as a list, outputs; endpoints that make one file return output. Each endpoint’s guide, such as New sample, describes its result and has a complete example using this client; the exact fields are in the API Reference, e.g. create.new_sample (submit).

Keeping an idempotency key across re-runs

run makes a new idempotency key each time you call it, and reuses that key for every retry inside the call. That covers a dropped connection or a busy moment. It does not cover your own program stopping: if it crashes or restarts after submitting, calling run again sends a new key, which starts the work again and charges for it again. To make a job survive a restart, create its key yourself, save it with your own record of the job before the first call, and pass it to run every time. Sending the same key again returns the original operation instead of starting new work, so run simply carries on waiting for it.
In a real application the key belongs in your database, in the same row as the job it identifies. Use one key per job: a key that was already used for a different endpoint is refused with a 422.

Making it your own

The file is yours to change. Before you do, read the production checklist: it lists what any client of the API should do, whether it is this one or one you write yourself.