A web content item is a URL plus the fields below. All of them are set the same way, by patching the asset.
curl -X PATCH \
'https://api.screenlyapp.com/api/v4.1/assets?id=eq.<asset-uuid>' \
-H "Authorization: Token $SCREENLY_API_TOKEN" \
-H 'Content-Type: application/json' \
-d '{"zoom_level": 150, "send_metadata": true}'| Field | What it does | Accepts |
|---|---|---|
headers | HTTP headers the player sends with its request | Object, up to 50 entries |
js_injection | Script run against the page after it loads | String, up to 65,536 characters. Write-only |
send_metadata | Player identifies itself to the page in X-Screenly-* headers | Boolean, default false |
client_cert_allowed | Player presents its device certificate | Boolean, default false |
zoom_level | Page scale, as a percentage | 25 to 500, default 100 |
user_agent | Overrides the user agent string | String, up to 1,024 characters |
player_side_render | Render on the device rather than as a server screenshot | Boolean, or null to let Screenly choose |
screenshot_cache_seconds | How long a captured screenshot is reused | 60 to 86,400, default 60 |
screenshot_delay_seconds | Wait after load before capturing | 0 to 5, default 0 |
disable_verification | Skip the reachability check when adding the URL | Boolean, default false |
Version matters here
Only headers, js_injection, send_metadata and disable_verification are updatable in v4. The rest of that table does not exist on the v4 asset at all, so patching one against /v4/ is rejected rather than ignored.
Target /v4.1/. See Versions.
Reading them back
GET returns every field except js_injection, which comes back as a placeholder. Headers come back in full, tokens included, which is worth knowing before you decide where to keep a credential. See Authentication.
Fields that do nothing on their own
client_cert_allowed needs a server configured to ask for the certificate. send_metadata needs a page that reads the headers. screenshot_cache_seconds and screenshot_delay_seconds apply only when the page is rendered on our side, which is the Screenly Anywhere path. Setting any of them on content that does not meet the condition is harmless and has no effect.
The complete schema, every field and filter on every endpoint, is in the v4.1 API reference.