--- title: Loading Viewer Data | Avara description: For companies and platforms that host Avara Viewer, or that are not using Avara PACS as the archive. Presigned blob URLs — no DICOMweb, no C-MOVE. --- This page is for **companies and platforms** that want to host the Avara Viewer in their product, or that are **not** using Avara PACS as their archive. If the DICOM files live in your system, you wire how the viewer gets them. If Avara PACS is the archive, Avara handles ingest and fetch — the same launch model still applies. Modalities still send studies into an archive the way they always have — **C-STORE** (and the rest of DIMSE) from the scanner into Avara PACS or yours. That path is ingest. It is not how the viewer opens a study. The Avara Viewer does **not** speak DICOMweb and does **not** run C-MOVE, C-GET, or other DIMSE retrieve. When a study launches, the viewer is handed a list of **presigned HTTPS URLs** into blob storage (S3-compatible object storage, or Avara’s archive). It **GETs those objects** and **parses them just in time** — frames become usable as they arrive, not after a full study lands on disk. That is more secure than handing the browser a DICOM node, much faster than retrieve-over-DIMSE, and a better reading experience. How those URLs are minted depends on who holds the pixels. ## Avara PACS If **Avara PACS** is the archive, Avara handles **DICOM node setup with the facilities and sites** — AE titles, routing, worklist, and C-STORE from the modalities into Avara storage. You do not stand that up yourself. Once the objects are in the archive, opening a study is a different path. The viewer session is authorized, short-lived GET URLs are issued against Avara storage, and pixels stream in. You do not implement Study Data or Secondary Capture for image fetch. Leave those blank — see [What webhooks should I configure](/integration/viewer/what-webhooks-should-i-configure/index.md). ## Your archive If **your PACS** (or platform) is the archive, you store the DICOM files. Modalities still C-STORE into **your** nodes the usual way. When a viewer instance launches, Avara POSTs `study.access_requested` to your **Study Data** webhook. Your backend looks up that study and returns **presigned GET URLs** into your blob storage for the DICOM objects (and optional non-DICOM media). The viewer then fetches those URLs directly. Avara never takes over your archive in that model. Implement the webhook on [What webhooks should I configure](/integration/viewer/what-webhooks-should-i-configure/index.md) and the language pages under Viewer → Webhooks. Return `authorized: false` to deny a study; `authorized: true` with an empty `urls` list means no data, not a denial. Secondary capture is the reverse direction: Avara asks for **presigned PUT** URLs so a new series can be written back to **your** storage. Annotations save in Avara without that webhook. ## Server to server The browser never sees your storage keys, and it never talks DICOMweb to your PACS. 1. Avara already knows **which study** and **which session** is opening (a logged-in Avara user, or a temporary access view you minted). 2. Avara calls **your** HTTPS endpoint. The body is signed with Standard Webhooks (`webhook-id`, `webhook-timestamp`, `webhook-signature`). You verify with `unwrap()` and `AVARA_WEBHOOK_KEY` — a forged or replayed POST does not pass. 3. Your server decides if that study may be read, then mints **short-lived, object-scoped** GET URLs (typical blob signing: verb, key, expiry). Those URLs are useless after they expire and are not a master key to the bucket. 4. The viewer GETs the objects over TLS. Avara’s API key never ships to the client. That is why a leaked viewer tab does not equal a leaked archive: the session can only fetch what you just signed, for a short window. ## Who authenticates the human Two ways in. Both end in the same webhook-and-presigned-URL path for pixels. **Avara login** — You invite the user; they set a password and sign into the Avara dashboard (or the product UI). Avara holds the session. When they open a study, Avara already knows `usr_…` and `stu_…` before it asks your archive for URLs. Stolen dashboard cookies are still bound to that user and that org’s studies — not to your bucket credentials. **Temporary access views** — The user never logs into Avara. They are already authenticated **in your app**. Your **backend** (API key stays on the server) calls `rerouteURL` / `reroute_url` and gets a **one-time, short-lived** link. You open that link in a new window. The API key never reaches the browser; the user cannot mint a second study URL without going through you again. Same Study Data webhook after that for pixels. See [Viewer temporary access views](/integration/viewer/temporary-access-views/index.md) (or [AutoScribe](/integration/autoscribe/temporary-access-views/index.md) if they are dictating). In both cases the **pixel path** is server-to-server then short-lived blob GET. The **person path** is either Avara’s login or a link only your servers can create. For how loading feels in the product (drag and drop, streaming, hanging protocols), see [Loading Data](/viewer/loading-data/index.md).