This route covers the Spotify Ads partner conversions API from the TrackLayer side. Spotify does not provide a standard click id flow here, so match quality comes from normalized and SHA-256 hashed identifiers. The implementation path is simple when auth, account scope, and event shape are verified in that order.
Spotify Ads uses OAuth2 bearer authentication. Delivery is tied to the configured advertiser_id and conversion_id.
TrackLayer should emit event_name, event_time, hashed user_data, and revenue fields when the event represents a purchase.
Prepare access, identifiers, and a controlled test flow before you send production conversions.
Spotify Ads API access with advertiser_id, conversion_id, and an OAuth2 access token enabled for conversion delivery.
A TrackLayer workspace with the Spotify Ads destination active and access to the live event inspector.
Reliable source fields for email, phone, and any mobile advertising id you collect with consent before hashing.
Canonical TrackLayer events already mapped to purchase, signup, and lead.
A controlled staging or low volume traffic path for test events before production rollout.
Work from credentials to payload validation so each failure class is isolated before launch.
Create a Spotify Ads destination in TrackLayer and store the access token, advertiser id, and conversion id together. TrackLayer uses those values for conversion scoped delivery.
SPOTIFY_ADS_ACCESS_TOKEN=sp_access_123
SPOTIFY_ADS_ADVERTISER_ID=987654321
SPOTIFY_ADS_CONVERSION_ID=123456789Spotify Ads uses an application token flow. Test auth first so you can separate credential and scope failures from payload validation failures later in the dashboard.
curl --request POST \
--url https://accounts.spotify.com/api/token \
--header "Content-Type: application/x-www-form-urlencoded" \
--user "SPOTIFY_ADS_CLIENT_ID:SPOTIFY_ADS_CLIENT_SECRET" \
--data "grant_type=client_credentials"Keep the map narrow and deterministic. In most deployments checkout becomes purchase, account creation becomes signup, and qualified form submission becomes lead. Use the same map for replay and live traffic.
{
"purchase_completed": "purchase",
"account_created": "signup",
"lead_submitted": "lead"
}Spotify standard matching is identifier based, not click based. Lowercase email, trim whitespace, normalize phone to a stable international form, then SHA-256 hash before TrackLayer sends the payload. Hash any consented advertising id as well.
{
"user_data": {
"email_sha256": "b4c9a289323b21a01c3e940f150eb9b8...",
"phone_sha256": "422ce82c6fc1724bca6c2b8d54735a8b...",
"device_advertising_id_sha256": "f2c7f13d7c395cdf1c8f8a3f4e31c1d9..."
}
}TrackLayer posts to the Spotify Ads conversions endpoint after token issuance. Include advertiser_id, conversion_id, an events array, and event level fields. Revenue events should include numeric value and ISO currency.
curl --request POST \
--url https://ad-studio-api.spotify.com/v1/conversions \
--header "Authorization: Bearer ACCESS_TOKEN" \
--header "Content-Type: application/json" \
--data "{\"advertiser_id\":\"987654321\",\"conversion_id\":\"123456789\",\"events\":[{\"event_name\":\"Purchase\",\"event_time\":\"2026-04-24T10:15:00Z\",\"event_details\":{\"amount\":129.99,\"currency\":\"EUR\"},\"user_data\":{\"hashed_email\":\"b4c9a289323b21a01c3e940f150eb9b8...\",\"hashed_phone_number\":\"422ce82c6fc1724bca6c2b8d54735a8b...\"}}]}"Create one controlled purchase or signup and inspect it before wider rollout. Confirm the mapped event_name, UTC event_time, hashed identifiers, outgoing endpoint, response code, and replay behavior.
TrackLayer Dashboard
Events → Open one Spotify eligible event
Inspect → Destination: Spotify Ads
Review:
- event_name matches purchase, signup, or lead
- event_time is UTC
- user_data contains hashed identifiers only
- response status is 2xx
- replay sends the same payload shapeKeep the event schema narrow and predictable. Spotify failures are usually field quality failures, not transport failures.
{
"event_name": "purchase",
"event_time": "2026-04-24T10:15:00Z",
"value": 129.99,
"currency": "EUR",
"user_data": {
"email_sha256": "b4c9a289323b21a01c3e940f150eb9b8...",
"phone_sha256": "422ce82c6fc1724bca6c2b8d54735a8b...",
"device_advertising_id_sha256": "f2c7f13d7c395cdf1c8f8a3f4e31c1d9..."
}
}event_name should stay inside the mapped set: purchase, signup, or lead.event_time should be ISO 8601 in UTC and should not change between retry attempts.user_data should contain hashed identifiers only. Raw email or phone should not leave your normalization layer.value and currency should be included for revenue events so the delivered conversion carries monetary context.Use the dashboard as the source of truth for every validation pass before broader rollout.
Generate a single purchase or signup from a test identity so the payload is easy to inspect without mixed production noise.
Confirm email and phone are transformed before hashing and that no raw identifiers appear in the destination payload.
The outgoing request should target the ad account specific conversions endpoint and include the right advertiser boundary.
A healthy send finishes with 2xx and no retry queue. Record the result before you widen traffic.
Use the replay control in TrackLayer to verify the second send keeps the same event_time source, identifier hashes, and event mapping.
These are the rejection patterns that usually appear during the first live Spotify Ads deployment.
Confirm the access token is current and the advertiser_id plus conversion_id pair is correct. A valid token on the wrong conversion scope still fails delivery.
Check normalization before hashing. Email should be lowercase and trimmed. Phone should be stable and international before SHA-256. Add more than one consented identifier when your collection flow allows it.
Review event_name, event_time, value, currency, and user_data keys first. event_time should be ISO 8601 in UTC. value should be numeric and currency should be a real ISO 4217 code such as USD or EUR.
Open the destination log for the failing event and compare the original send with the replay payload. If required hashed identifiers are missing upstream, fix collection first and replay after the source event is complete.
Use this list before switching the Spotify Ads destination from a controlled test flow to real traffic.
Spotify Ads partner access is approved for conversion delivery.
access_token is stored in the TrackLayer destination.
advertiser_id and conversion_id are configured and verified.
The OAuth2 access token is current.
TrackLayer event names map only to purchase, signup, or lead.
Email and phone are normalized before SHA-256 hashing.
Revenue events include numeric value and ISO currency.
A controlled test event returns 2xx in the TrackLayer dashboard.
A clean Spotify Ads setup is visible in the dashboard before it is visible in ad reporting.
In the TrackLayer event detail view you should see a deterministic destination trace: token ready, mapped event_name, hashed user_data fields present, endpoint scoped to the right ad account, and a successful response. If any one of those steps is missing, fix that layer first instead of widening traffic.
Spotify rejections usually come from scope mismatches, malformed user_data, or a revenue field problem. TrackLayer makes those visible immediately, which is why the best testing loop is dashboard inspection first, replay second, and only then gradual rollout.
We use essential cookies to keep the site secure and functional. Analytics and third-party tags run only with your consent. See our Cookie Policy.
We use essential cookies to keep the site secure and functional. Analytics and third-party tags run only with your consent. See our Cookie Policy.