Recording URLs

Every 2.1 call that resolves a container — redirect, retarget, modify — returns the same four URL fields. Three of them are fixed. The fourth, url, is not, and that difference is the single most consequential fact in this API.

The four fields

urlRead, urlWrite and urlPreview each point at exactly one destination, always. url is the historical default, and it is the one field whose target depends on the calling platform.

URL fields
Field	Always points to
urlRead	https://{domain}/{urid} — the recipient-facing read URL
urlWrite	https://{domain}/overwrite/{urid} — the sender-facing overwrite URL
urlPreview	https://{domain}/preview/{urid} — the legacy preview URL
url	urlWrite when the platform carries the default_message service, urlRead otherwise

url depends on the platform

url exists for backward compatibility with integrations that only ever read one field. It resolves to urlWrite when the calling platform carries the default_message service, and to urlRead for every other platform. The same call, made with two different API keys, can return two different destinations in url.

Two responses, side by side

The same redirect call against a standard platform and against a platform carrying default_message — only url differs between the two.

standard platform

{
  "status": 0,
  "urid": "5f3e9c2b8a1d4f60",
  "urlRead": "https://livstick.io/5f3e9c2b8a1d4f60",
  "urlWrite": "https://livstick.io/overwrite/5f3e9c2b8a1d4f60",
  "urlPreview": "https://livstick.io/preview/5f3e9c2b8a1d4f60",
  "url": "https://livstick.io/5f3e9c2b8a1d4f60",
  "messageUrl": "livstick.io/5f3e9c2b8a1d4f60"
}

default_message platform

{
  "status": 0,
  "urid": "5f3e9c2b8a1d4f60",
  "urlRead": "https://livstick.io/5f3e9c2b8a1d4f60",
  "urlWrite": "https://livstick.io/overwrite/5f3e9c2b8a1d4f60",
  "urlPreview": "https://livstick.io/preview/5f3e9c2b8a1d4f60",
  "url": "https://livstick.io/overwrite/5f3e9c2b8a1d4f60",
  "messageUrl": "livstick.io/5f3e9c2b8a1d4f60"
}

messageUrl keeps the old format

messageUrl is not a fifth alternative to url — it is the historical domain/{urid} format, kept for integrations built before the url* fields existed. It carries no scheme, unlike urlRead, urlWrite, urlPreview and url, which are all complete HTTPS URLs.

The QR code always encodes urlRead

Whatever url resolves to for a given platform, the QR code generated for a container always encodes urlRead — the recipient-facing read URL, never the overwrite or preview destination.