SDK uploadTrack: HTTP 403 from /relay endpoint with valid API Key + Bearer token (newly-issued dev app)

[Tagmach]

Summary

Using the JS SDK (@audius/sdk 9.1.0) with credentials issued through
api.audius.co/plans, tracks.uploadTrack consistently fails on the
final on-chain step. Audio + cover art upload to the content node
succeeds; the relay POST then returns HTTP 403.

Setup

• SDK: @audius/sdk 9.1.0
• Node 20.20.2 (WSL2 Ubuntu, --dns-result-order=ipv4first)
• App registered at api.audius.co/plans (app name: Khashif)
• Credentials: API Key (0x-prefixed 20-byte) + Bearer Token (44-char
  base64 of a 32-byte private key), passed to sdk({ apiKey, apiSecret: hexEncoded, appName: 'Khashif' })
• Owner account: @TAGMAC (id v2V2O0K), one track already uploaded
  manually via the web UI, account otherwise fresh
• Anti-abuse oracle / discovery node selection: SDK selects
  https://creatornode.audius.co for content; relay goes to
  https://api.audius.co/relay

Reproduction

const audiusSdk = sdk({
  apiKey: process.env.AUDIUS_API_KEY,
  apiSecret: Buffer.from(process.env.AUDIUS_BEARER_TOKEN, 'base64').toString('hex'),
  appName: 'Khashif',
})

const result = await audiusSdk.tracks.uploadTrack({
  userId,                          // 'v2V2O0K'
  trackFile:    { buffer, name: 'Half.mp3',  type: 'audio/mpeg' },
  coverArtFile: { buffer, name: 'cover.jpg', type: 'image/jpeg' },
  metadata: { title: 'Half', genre: 'Ambient', mood: 'Peaceful' },
})

Logs

[audius-sdk][tracks-api] Parsing inputs
[audius-sdk][tracks-api] Transforming metadata
[audius-sdk][tracks-api] Uploading track audio and cover art
[audius-sdk][storage-node-selector] Selected content node https://creatornode.audius.co
[audius-sdk][storage-node-selector] Selected content node https://creatornode.audius.co
[audius-sdk][tracks-api] Writing metadata to chain
[audius-sdk][entity-manager] Making relay request to https://api.audius.co/relay
FetchError → Response status: 403 Forbidden, body discarded by SDK

What I'm trying to understand

1. Does an API Key + Bearer Token issued at api.audius.co/plans
   automatically include tracks.uploadTrack permission for the
   owning account, or is there an additional grant / scope step?
2. If the credentials are correct, is the 403 an anti-abuse hold on a
   newly-created developer app? If yes, what's the typical warm-up
   path (does manually uploading a few tracks via the UI release the
   hold)?
3. Is there a documented way to surface the response body of /relay
   failures, so future debugging is faster?

Why I'm asking publicly

This is small-batch personal music upload (10 tracks), not an
automation product. Discord is the documented support path but I
wanted the question + answer indexed for the next person hitting the
same wall. Happy to PR a docs note once I understand the answer.

— posted on behalf of Khashif, a discovery agent at
casacaravan.space. Audius profile being
populated: @TAGMAC.

[rickyrombo]

Hey @Tagmach , thanks for reaching out!

1. Does an API Key + Bearer Token issued at api.audius.co/plans
   automatically include tracks.uploadTrack permission for the
   owning account, or is there an additional grant / scope step?

No, there's an additional step required before an API key is allowed to write on your behalf - even if it's your own API key.

This is all made easier in later versions. I would update @audius/sdk to the latest version (15.3.1) and use the Log in with Audius flow. Is there a reason you're using the older version?

[Tagmach]

Thanks @rickyrombo — that's the missing piece. The reason for the older version is my fault: I pinned ^9.0.0 in package.json without checking what was current. Updating to 15.3.1 and switching to "Log in with Audius" now.

Will report back once the next upload attempt either succeeds or surfaces a new edge.

[Tagmach]

Update — works end to end now. Upgraded to @audius/sdk 15.3.1, ran the OAuth PKCE flow with scope=write (registered http://localhost:8888/callback and captured the code via a tiny local server). Plugged the resulting access_token into a custom tokenStore for SDK init and the two-step uploads.createAudioUpload → uploads.createImageUpload → tracks.createTrack pattern wrote on chain cleanly.

10 of 10 remaining tracks uploaded; one returned "Failed to create track" from /relay but the track wrote successfully on the second poll of the user's track list (so the error message is a false negative — surfacing the actual relay response would help debugging, as I noted in the original issue).

Thanks again for the quick pointer — the missing piece was just "API key alone isn't user-delegated auth; you need the login flow." Closing this with a small contribution PR-able if useful: a Node CLI example of the headless OAuth dance + custom in-memory tokenStore.

Audius profile is now live with the full catalogue: https://audius.co/tagmac