Identifiers: crid, urid and editKey
A container carries three identifiers, and each answers a different question: which reference is yours, which one Livstick assigns, and which one grants write access from a browser.
Before this page
This page assumes the container/message split from the previous concept page. Containers and messages
crid — your reference
The crid is the identifier you choose when you create a container. It is the key to every server-side call that follows: retrieving the container, updating it, triggering delivery, unlocking the message. Pick something that already means something in your system — an order id, a card id, a code from packaging.
Creation is idempotent
Creating a container with a crid that already exists does not create a second one, and does not mutate the first. The server returns the existing container’s links as they stand today.
- Containers reference
- The operation that creates a container and returns crid, urid and editKey together.
urid — the Livstick identifier
The urid is assigned by Livstick, not by you. It is the identifier that appears in URLs, and the one a widget mounts against: the Recorder and the Viewer both take a urid, never a crid.
- Choosing an integration mode
- Where the Recorder mounts against a urid to write a message.
- Viewer widget
- Where the Viewer mounts against a urid to read a message back.
editKey — the right to write from a browser
The editKey grants write access to one specific container from client-side code, without exposing your API key. It is what lets the Recorder widget live safely on a public page.
At a glance
The three identifiers side by side, with who chooses each one and what it is for.
| Identifier | Chosen by | Used for |
|---|---|---|
| crid | You, at creation | Every server-side API call against the container |
| urid | Livstick, at creation | URLs, and mounting the Recorder or Viewer widget |
| editKey | Livstick, at creation | Granting write access to the container from a browser, without exposing your API key |