Use the AzuraCast Now Playing API on a Website

What this guide helps you do

Fetch station metadata safely, understand public API responses and build a resilient frontend integration. AzuraCast exposes Now Playing information that can power website players, “currently playing” cards and programme metadata. Public data is ideal for frontend display; administrative actions require authentication and should stay on the server side. API structures can evolve, so code should handle missing fields gracefully. This guide is written for production-minded administrators and site owners: make a backup before material changes, keep credentials private, and prefer the controls supplied by your own hosting provider when its environment differs from a generic example.

Before you begin

Record the domain, server or station you are changing and the current working state. If the task touches DNS, SSH, firewall rules, databases, stream credentials or application configuration, make sure you have a recovery path first. Screens and menu names can vary between cPanel, AzuraCast, VDO Panel and Linux releases, so follow the purpose of each step rather than forcing an old screenshot onto a newer version.

Step 1: Identify the station’s public Now Playing endpoint from the AzuraCast API documentation or your installation. Common deployments expose a station-specific response beneath an /api/nowplaying/ path.

Identify the station’s public Now Playing endpoint from the AzuraCast API documentation or your installation. Common deployments expose a station-specific response beneath an /api/nowplaying/ path.

Step 2: Open the JSON response in a browser and identify the fields you actually need: station name, song text, artwork, listeners, elapsed time or playing-next data. Do not hard-code assumptions about every optional field.

Open the JSON response in a browser and identify the fields you actually need: station name, song text, artwork, listeners, elapsed time or playing-next data. Do not hard-code assumptions about every optional field.

Step 3: For browser JavaScript, fetch only a public endpoint that permits your site origin. If CORS or authentication is required, create a small server-side proxy that exposes only the fields your public page needs.

For browser JavaScript, fetch only a public endpoint that permits your site origin. If CORS or authentication is required, create a small server-side proxy that exposes only the fields your public page needs.

Step 4: Refresh on a sensible interval rather than every second. Cache or debounce requests so a popular website does not create needless load on the radio panel.

Refresh on a sensible interval rather than every second. Cache or debounce requests so a popular website does not create needless load on the radio panel.

Step 5: Render fallbacks for missing artwork and metadata, and escape text before inserting it into HTML. Treat API responses as external data even when they come from your own station.

Render fallbacks for missing artwork and metadata, and escape text before inserting it into HTML. Treat API responses as external data even when they come from your own station.

Useful commands or examples

The following commands are examples for the context described in this guide. Read them before running them, substitute your real service names or hostnames, and keep a working administrative session open for network or SSH changes.

curl -s https://radio.example.com/api/nowplaying/station_short_name | head

Verification checklist

Confirm the endpoint is intentionally public, no API key is exposed in browser source, the site survives missing artwork/metadata, request frequency is reasonable, and the integration is tested when the station is live and when it is on AutoDJ. Always test from the user side as well as the administrator side. A control panel saying “active” is useful evidence, but it is not the same as an external browser, player or SSH client proving that the full path works.

Troubleshooting method

When the result is not what you expected, avoid changing several unrelated settings at once. Identify the last known-good point, collect the exact error message and determine which layer is failing: DNS, network, authentication, service process, application configuration, web/stream delivery or browser/player. Check timestamps and logs around the failure. If you need to escalate to hosting support, include the affected hostname or station, the time of the test, what you expected, what happened instead and the checks you already completed. Do not include passwords, API keys or private stream keys in a public ticket or screenshot.

Keep the system maintainable

Document the final configuration after it works. Note the important URLs, service names, backup locations, renewal/expiry dependencies and any change that would surprise another administrator. Revisit the setup after major platform upgrades because defaults, supported runtimes and interface labels evolve. A reliable environment is not one that was configured once; it is one whose current state is understood, monitored and recoverable.

Where to go next

Use the related guides below to expand the setup rather than solving the same problem from scratch. If the platform has outgrown shared hosting or you need managed implementation, the service recommendation at the bottom of this guide links to the most relevant hosting, streaming, development or optimisation option on this site.