# Sending screen details to a page


> Turn on Send metadata and the player identifies itself in HTTP headers, so one URL can show different content per location.
One dashboard URL, twenty sites, and each screen should show its own site's numbers. Without help that means twenty URLs to maintain.

**Send metadata**, on the content item under Advanced, solves it. The player adds headers to its request identifying itself, and your page reads them and returns the right content.

## What is sent

```json
{
  "X-Screenly-hostname": "srly-jmar75ko6xp651j",
  "X-Screenly-screen-name": "dizzy cherry",
  "X-Screenly-location-name": "Cape Town",
  "X-Screenly-hardware": "x86",
  "X-Screenly-version": "v2",
  "X-Screenly-lat": "-33.925278",
  "X-Screenly-lng": "18.423889",
  "X-Screenly-tags": "srly-jmar75ko6xp651j,custom-label"
}
```

`X-Screenly-tags` carries the screen's [labels](/docs/labels/), which is usually the most useful one: label your screens by site and your page can branch on the label rather than on a list of screen names.

## Using it

Read the headers server-side and return content accordingly. Because they are request headers rather than query parameters, they do not appear in the URL, are not cached by anything keyed on the URL alone, and do not end up in browser history or a shared link.

## Two things to get right

**Do not trust these for access control.** They identify the screen conveniently; they do not authenticate it. Anything sensitive needs real authentication. See [Authenticated pages](/docs/content/web-pages/authenticated-pages/).

**They only reach the page when the device makes the request.** A page rendered on our side, the Screenly Anywhere screenshot path, is fetched by our infrastructure rather than by the player.

## Off by default

Existing content is unaffected until you turn it on, and there is no reason to enable it for a page that does not read the headers.