Overview

To set up and test Signal workflows in Sandbox, you will need to follow the same steps required to configure Signal in production. The one key difference is that you will need to create a query for your test patient in Sandbox. Signal alerts are then produced from that query and sent to your registered callback endpoint, just as in production. To test ADT notifications, Network Alerts, Transition Alerts, and Medication Fills, you can also trigger simulated events with the Trigger Sandbox Workflow API. You can find more information on setting up Signal here.

We have established a suite of Postman collections that enable you to configure and test Signal workflows in our Sandbox environment.

1. Authenticate

Generate a JSON web token using Authentication.

2. Register a Sandbox Test Patient

Use the POST /api/v2/patients endpoint to create a patient.
The TRANSITION_ALERT and MEDICATION_FILLS_ALERT workflows and alerts from queries you submit require a Sandbox test patient, such as Elvira Valadez below. ADT and Network Alert simulations work for any registered patient.
Only the patients marked in the Has Transitions Data column contain Transition Alert data.

Sample Request

{
    "address_city": "Boston",
    "address_lines": [
        ""
    ],
    "address_state": "MA",
    "date_of_birth": "1970-12-26",
    "email": "[email protected]",
    "family_name": "Valadez",
    "gender": "Female",
    "given_name": "Elvira",
    "npi": "",
    "postal_code": "02215",
    "ssn": "",
    "telephone": "1-234-567-8910",
    "patient_id": "test-elvira-valadez"
}

The patient_id must be unique for each patient you register.

Sample Response

{
    "given_name": "Elvira",
    "family_name": "Valadez",
    "date_of_birth": "1970-12-26",
    "gender": "FEMALE",
    "ssn": "",
    "email": "[email protected]",
    "address_lines": [
        ""
    ],
    "address_state": "MA",
    "address_city": "Boston",
    "postal_code": "02215",
    "telephone": "(234) 567-8910",
    "patient_id": "test-elvira-valadez",
    "particle_patient_id": "d939196d-0c80-4e82-b0e1-19f9ee271085",
    "consent": null
}

3. Subscribe patients to Signal monitoring - Optional

NOTE this step is only necessary if you want to specify a subset of patients to monitor. If you want to monitor ALL of your patients, you can reach out to your Particle representative to automatically enable Signal for all patients for your organization.

Subscribe your patient(s) to Signal notifications via the Subscriptions API.

Sample Request for Individual Patient

{
  "subscriptions": [
    {
      "type": "MONITORING"
    }
  ]
}

Sample Response

{
  "subscriptions": [
    {
      "id": "39774a2f-b6fb-46a0-88c9-30843a5127b7",
      "type": "MONITORING"
    }
  ]
}

4. (Sandbox-Only) Create a Query

Using the particle_patient_id you received in step 2, trigger a query for the patient using POST /api/v2/patients/{particle_patient_id}/query

See Create Query API.

The query request requires a purpose_of_use. To receive Medication Fills, use TREATMENT.

5. Receive Signal Alerts

When you submit a query yourself, Signal alerts arrive at your registered callback endpoint the same way as in production, for the features enabled on your Sandbox project:

• Transition Alerts: to test Transition Alerts, use the TRANSITION_ALERT workflow.
• AI Outputs (patient history, event discharge, discharge summary, and specialty summaries) and New Encounter Alerts: contact your Particle representative to enable them for your Sandbox project. Once enabled, they arrive from your queries the same as in production. As in production, New Encounter Alerts only cover encounters from the last 30 days, so they arrive only when the patient's Sandbox data includes recent encounters. There is no trigger workflow for these.
• Medication Fills: to test any time, use the MEDICATION_FILLS_ALERT workflow. To get fills from your own queries, submit them with a purpose_of_use of TREATMENT and ask your Particle representative to enable Medication Fills (Surescripts). The webhook arrives after the query completes.

Set up your callback endpoint the same way as in production. See Setting Up Signal.

For an example Transition Alert webhook, see Transition Alerts.

6. Retrieve the Data

Using the Data Retrieval APIs you can retrieve the data related to that alert.

For example, using GET /api/v2/patients/{particle_patient_id}/flat you can retrieve all of the data in the flat format for that patient. If you are specifically looking for a resource, like the Transitions table, you can use GET /api/v2/patients/{particle_patient_id}/flat?TRANSITIONS to return just the transitions table for that patient.

If you want to pull the files related to the alert, you can use GET /api/v2/patients/{particle_patient_id}/ccda?file_id={file_id}.

Simulating ADT, Network, Transition, and Medication Fills Alerts

To test ADT notifications, Network Alerts, Transition Alerts, and Medication Fills, use the Trigger Sandbox Workflow API:

POST /api/v1/patients/{particle_patient_id}/subscriptions/trigger-sandbox-workflow

The patient only needs to be registered in your project. A Signal subscription is not required.

Valid workflow values:

Every other workflow value returns 400.

Sample Response

{
    "message": "success",
    "query_id": "5b7c2b4e-0f4c-4b8e-9d7b-6a3f1c2d8e90",
    "callback_urls": ["https://your-webhook-receiver"]
}

callback_urls lists the endpoints registered on your project that the alert was sent to. Endpoints registered on your parent organization also receive the alert but aren't listed, so callback_urls is left out when your only endpoint is organization-level. query_id is included for workflows that run a query, so ADT responses don't include it.

ADTs

1. Request an ADT notification using the Trigger Sandbox Workflow API.

Request Body:

{
    "workflow": "ADT",
    "event_type": "A01"
}

2. You will receive a notification at your registered callback endpoint. This notification will contain the Patient ID and a message ID.
3. Retrieve the sample ADT message using the HL7v2 API.
   GET /hl7v2/{message_id}

Sample ADT messages are customized based on the patient and ADT event type specified.

Network Alerts

A Network Alert simulates another organization on a health network (Carequality or CommonWell) requesting the patient's records, which is an inbound ITI-55 request.

1. Request a Network Alert using the Trigger Sandbox Workflow API. No event_type is needed.

Request Body:

{
    "workflow": "NETWORK_ALERT"
}

2. Particle immediately sends a Network Alert webhook to your registered callback endpoint.
3. In the background, Particle also starts a query for the patient, just as Particle does in production after a Network Alert. Other Signal alerts from that query, such as AI Outputs, arrive if those features are enabled for your project. As in production, Transition Alerts from this query only cover the last 30 days, so they arrive only when the patient's Sandbox data includes recent transitions. To test Transition Alerts, use TRANSITION_ALERT.

• Webhook Type: com.particlehealth.api.v2.networkalert
• Example Webhook Payload:

{
  "specversion": "1.0",
  "type": "com.particlehealth.api.v2.networkalert",
  "subject": "Network Alert from 0 Organizations",
  "source": "api/notifications",
  "id": "7e2b9c41-5a3d-4f8e-b6c2-1d9a0e3f5b78",
  "time": "2026-09-30T20:36:07Z",
  "datacontenttype": "application/json",
  "data": {
    "network_alert_ids": ["3f1c2a9e-8b7d-4c6e-9a51-2d0f7e4b6c13"],
    "particle_patient_id": "d181082c-a758-4fb1-a0ef-cb112d77aec3",
    "external_patient_id": "your-patient-id",
    "alert_time": "2026-09-30T20:36:07Z",
    "network_organizations": [],
    "next_scheduled_query": "2026-09-30T20:36:07Z"
  }
}

Transition Alerts

1. Request Transition Alerts using the Trigger Sandbox Workflow API.

Request Body:

{
    "workflow": "TRANSITION_ALERT"
}

2. The response includes a query_id. One webhook arrives for each transition in the patient's data.

• Webhook Type: com.particlehealth.api.v2.transitionalerts
• Example Webhook Payload:

{
  "specversion": "1.0",
  "type": "com.particlehealth.api.v2.transitionalerts",
  "subject": "Admit Alert",
  "source": "api/notifications",
  "id": "1acf0bef-86f6-420a-abc6-483e4ed36959",
  "time": "2026-09-30T22:14:15Z",
  "datacontenttype": "application/json",
  "data": {
    "particle_patient_id": "d181082c-a758-4fb1-a0ef-cb112d77aec3",
    "external_patient_id": "your-patient-id",
    "event_type": "admission",
    "event_sequence": -1,
    "is_final_event": "Unknown",
    "network_organization": { "name": "", "oid": "", "facilities": null },
    "resources": [
      {
        "file_id": "fd498926-007c-5d0c-ad83-b62baadc5c86",
        "resource_ids": ["transitions/1b7e4c2a-9d3f-4e6b-8a51-0c2f7d9e4a36"]
      }
    ]
  }
}

3. Retrieve the data for each alert:
   • Request (a specific transition): GET /api/v2/patients/{particle_patient_id}/flat?resource_type=TRANSITIONS&resource_id={transition_id}, using the ID from transitions/{transition_id}
   • Request (the source C-CDA): GET /api/v2/patients/{particle_patient_id}/ccda?file_id={file_id}

For field definitions and more retrieval options, see Transition Alerts.

The number of alerts and the file_id values can change between calls, because each query advances the synthetic record. Always use the IDs from the webhook you received.

Medication Fills

1. Request a Medication Fills alert using the Trigger Sandbox Workflow API.

Request Body:

{
    "workflow": "MEDICATION_FILLS_ALERT"
}

2. The response includes a query_id. One webhook arrives per call, after the query is complete. Sandbox fills are synthetic.

• Webhook Type: com.particlehealth.api.v2.medicationfills
• Example Webhook Payload:

{
  "specversion": "1.0",
  "type": "com.particlehealth.api.v2.medicationfills",
  "subject": "Medication Fills Data Available",
  "source": "api/notifications",
  "id": "9206931a-45b3-4f89-8685-44e563f9e9dd",
  "time": "2026-10-01T17:04:09Z",
  "datacontenttype": "application/json",
  "data": {
    "particle_patient_id": "ad5000cb-4647-4abf-84e6-a95057d84045",
    "external_patient_id": "your-patient-id",
    "query_id": "7c6d1ad5-f587-46ae-88d6-014504910005",
    "count": 3
  }
}

3. The payload has a count but no resource IDs. Retrieve the fills:
   • Request: GET /api/v2/patients/{particle_patient_id}/flat?MED_FILLS

Medications newly identified from the fills also appear in ?MEDICATIONS.