Shazam Core API Review: Song Recognition, Charts & Track Data

What Shazam Core does and who it is for

Shazam Core exposes the music-identification engine behind Shazam through a REST API hosted on RapidAPI. At its core, the API converts a short audio clip into a digital fingerprint and matches it against a database of millions of songs — the same technology that drives the consumer Shazam app. Beyond recognition, it layers on metadata retrieval (track details, album art, lyrics, video clips), discovery features (related and similar tracks), popularity signals (total Shazam counts), and pre-built chart lists for cities and countries.

The API is a good fit for:

• Mobile and web apps that need "what song is this?" functionality without building acoustic fingerprinting from scratch.
• Music dashboards that want to surface trending tracks by geography.
• Recommendation engines that need a quick similarity graph seeded from Shazam's listen data.
• Content platforms wanting to enrich a known track with metadata — cover art, YouTube clips, Shazam popularity — in a single round-trip.

Authentication is straightforward RapidAPI key injection via X-RapidAPI-Key and X-RapidAPI-Host: shazam-core.p.rapidapi.com headers. The provider also supports a x-portal-apikey header or query parameter for environments where RapidAPI proxying is not involved.

Endpoint walkthrough

Song recognition

The recognition endpoint (POST /v1/tracks/recognize) is the headline feature. You send a multipart/form-data request with an audio file attached as the file field. Supported formats are .wav, .ogg, and .mp3. The file must be under 1 MB (the docs flag ~500 KB as optimal), and the audio content only needs to be 2–4 seconds long for a reliable match. The API responds with the identified track, including metadata that can feed directly into the track-details endpoints.

At an average latency of 2,260 ms, expect roughly 2–3 seconds end-to-end. That is acceptable for a flow where the user taps a "listen" button and waits for a result, but would be noticeable in any near-real-time or batch-processing scenario.

Search

GET /v1/search/multi accepts a query string (2–50 characters) and a search_type of either SONGS or ARTISTS. The offset parameter (0–100) provides simple pagination. This is the right endpoint when you know a song title or artist name rather than having audio to recognize.

Track details — v1 and v2

Two versioned endpoints exist for fetching metadata on a known track:

• GET /v1/tracks/details?track_id=<id>
• GET /v2/tracks/details?track_id=<id>

Both accept an integer track_id, extractable from any standard Shazam track URL (e.g., the 216314 in shazam.com/track/216314/let-it-be). The documentation notes that v2 exists as an alternative; when integrating, it is worth testing both versions to see which returns the richer payload for your use case, since the provider has not spelled out the exact schema differences.

Discovery endpoints

Three endpoints support content discovery:

• Related tracks (GET /v1/tracks/related) — returns tracks editorially or algorithmically associated with a given track, with offset pagination.
• Similar tracks (GET /v1/tracks/similarities) — returns acoustically or stylistically similar tracks for a given track_id.
• Total Shazams (GET /v1/tracks/total-shazams) — returns the cumulative detection count for a track, useful as a popularity signal.

The distinction between "related" and "similar" is worth probing during integration. Related tracks may follow Shazam's editorial curation (e.g., same artist, same playlist family), while similarities appear to be computed from acoustic or listener-behavior proximity.

YouTube video lookup

GET /v1/tracks/youtube-video takes a track_id and a name string (5–40 characters, typically "Artist Title") and returns a YouTube video result. This is a convenience wrapper rather than a direct Shazam data source — it searches YouTube on your behalf — so treat the response as a best-effort match rather than a canonical music video link.

Pricing breakdown

The BASIC tier's 100 monthly requests is enough for development and smoke-testing but not for production use. A single user session that recognizes a track and then fetches its details, related tracks, and YouTube video could consume 4 requests; 100 requests would serve roughly 25 such sessions a month.

PRO at $10/month is the entry-level production tier. At 1,500 included requests plus $0.001 overage, it stays cheap for low-volume apps — 5,000 requests in a month costs $10 + $3.50 = $13.50. The 5 requests/second cap is unlikely to be a bottleneck at this scale.

ULTRA targets growing products. 100,000 requests at $49/month works out to $0.00049 per request on the base quota, with the same overage rate if you exceed it. The rate limit remains at 5/second, which constrains throughput to about 432,000 requests per day, well above the monthly allotment.

MEGA removes the request ceiling for $149/month and raises the rate limit to 10 requests/second. This is the tier for high-traffic applications or batch data pipelines that need to process large volumes without worrying about overage arithmetic.

Practical use cases

Music recognition apps: The most direct application. Capture a few seconds of ambient audio on a mobile device, POST it to /v1/tracks/recognize, then display the track name, artist, album art, and a YouTube clip — all fetchable in subsequent calls.

Chart and trending pages: Shazam's city and country chart data (referenced in the feature list, accessible via endpoints beyond the eight listed here in the OpenAPI spec) can power a "What's trending in Berlin?" feature without any editorial curation effort.

Content enrichment pipelines: If you already have a catalog of Shazam track IDs, you can batch-fetch details, total Shazam counts, and related tracks to enrich your internal music database. On the ULTRA plan, processing 100,000 tracks a month stays within the included quota.

Discovery widgets: The related and similar track endpoints give you enough signal to build a "You might also like" rail in a streaming or radio app without training your own recommendation model.

Limitations and things to check before integrating

• Latency: The 2,260 ms average is meaningful. If your UX requires a sub-second recognition response, this API will not meet that bar. Design your UI with a loading state.
• File size ceiling: The 1 MB (optimal 500 KB) cap on audio uploads means you should pre-process or trim audio on the client before sending. Raw microphone recordings can exceed this quickly if you capture more than a few seconds.
• No detailed schema documentation: The provider references an OpenAPI spec (at hugeapi.com/collection/shazam-core), but the response schemas are not reproduced in the fact sheet. Plan a short spike to inspect real responses before committing to a data model.
• BASIC overage handling: The BASIC plan lists no overage rate, implying requests are hard-capped at 100. Confirm this behavior so your app fails gracefully rather than silently dropping requests.
• Rate limits on lower tiers: The BASIC plan has no documented rate limit, which may mean it is lower than PRO's 5/second rather than higher — worth verifying.

Getting started

1. Subscribe via RapidAPI and grab your X-RapidAPI-Key.
2. Make a test call with a short .mp3 sample using cURL:

   curl -X POST "https://shazam-core.p.rapidapi.com/v1/tracks/recognize" \
     -H "X-RapidAPI-Key: YOUR_KEY" \
     -H "X-RapidAPI-Host: shazam-core.p.rapidapi.com" \
     -F "[email protected]"

3. Take the returned track_id and call /v1/tracks/details to inspect the full metadata payload.
4. Explore /v1/tracks/related and /v1/tracks/similarities to understand what discovery data looks like for your genre or use case.
5. Once you have a clear request-per-user-session estimate, use that to choose between PRO and ULTRA before going to production.