Early Access
Request early access
Docs navigation

Quickstart

A DICOM endpoint is a named bridge between a hospital’s imaging equipment and your HTTPS URL. The hospital side speaks DICOM — their CT scanner, PACS, or workstation opens a TLS connection and sends instances using the standard C-STORE protocol. The Dicomly side translates each instance into a STOW-RS HTTP request and posts it to your URL in real time. Nothing is stored in between.

To set up a DICOM endpoint you provide one HTTPS destination URL. Dicomly returns the DICOM connection details and a client certificate bundle that you hand to whoever configures the imaging equipment at the hospital. Once the sender is configured, deliveries start arriving at your URL automatically.

1. Create an endpoint in the console

Sign in to the console and create an endpoint with a name, your destination URL, and at least one certificate. No API key is needed — the console authenticates with your session.

The endpoint page shows the DICOM connection details (dicom_host, dicom_port, peer_ae_title) and the certificate bundle once — save it now.

2. Hand the connection details to the sender

Share these values with the team that configures the DICOM source (the hospital’s IT or biomedical engineering team, or your own device operator):

Sender setting API response field
Host dicom_host
Port dicom_port
Called AE title peer_ae_title
Client certificate certificate_pem
Client private key private_key_pem

3. Send a test image yourself

Before handing anything to the hospital, prove the endpoint works with a synthetic (no-PHI) sample DICOM file and the DCMTK storescu tool — the console’s endpoint page shows this same command, pre-filled with your connection details:

storescu +tls endpoint-bundle.pem endpoint-bundle.pem -pem +cf dicomly-ca.pem \
  -aec DICOMLY -ts 10 -ta 10 -td 10 \
  relay.dicomly.io 11112 synthetic-sample.dcm

Two files are involved. Your endpoint-bundle.pem appears twice — it is one file holding your certificate and its private key, passed as the certificate (+tls first argument) and the key (+tls second argument). The separate dicomly-ca.pem (the “Download Dicomly CA” button on the endpoint page, also at dicomly.io/ca.pem) is the trust anchor (+cf) your sender uses to verify the Dicomly server — the bundle can’t do this job, so pass the CA file here.

No DCMTK installed? Use the Docker one-liner shown on the same page instead.

Nothing happened? An unrecognized client certificate is rejected before the association opens and leaves no record anywhere — double check the certificate/key files match the endpoint.

4. Accept deliveries at your HTTPS endpoint

When the sender opens a DICOM association, Dicomly forwards each instance to your HTTPS destination as a standard STOW-RS request.

POST https://your-app.io/dicom
Content-Type: multipart/related; type="application/dicom"; boundary=…
X-Dicomly-Endpoint-Id: endpoint_01HXYZ
X-Dicomly-Cert-Id: cert_01J5ME
X-Dicomly-Request-Id: req_abc123

Respond with 200 or 202 when the instance is accepted. A temporary 5xx response tells the sender to retry later.

Automating it? Generate an API key

Creating endpoints from the console works for most teams. If you provision endpoints programmatically — from your own onboarding flow, a CI job, or an internal tool — generate an API key from the console’s API keys page and call the API directly:

curl -X POST https://api.dicomly.io/v1/endpoints \
  -H "Authorization: ******" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "MGH Radiology",
    "destination_url": "https://your-app.io/dicom",
    "certificates": [{ "label": "CT scanner" }]
  }'

The response returns the endpoint id, DICOM connection details, and the certificate bundle once — same shape as the console.

Next steps