Work with Devices

Device access is scoped through a patient or organization. Begin with a list request and keep the returned device ID as an opaque identifier.

List visible devices

Query by patient:

curl --fail-with-body --get \
  "https://api.memo.wirewire.de/v1/devices/" \
  --header "Accept: application/json" \
  --header "x-api-key: $MEMO_API_KEY" \
  --data-urlencode "patient=$PATIENT_ID" \
  --data-urlencode "limit=50"

Or query by organization:

curl --fail-with-body --get \
  "https://api.memo.wirewire.de/v1/devices/" \
  --header "Accept: application/json" \
  --header "x-api-key: $MEMO_API_KEY" \
  --data-urlencode "organization=$ORGANIZATION_ID" \
  --data-urlencode "limit=50"

At least one of patient or organization is required by the current API behavior.

Read device information

Useful read paths include:

• GET /devices/{deviceId} for the device record
• GET /devices/events/{deviceId} for device events
• GET /devices/alarms/{deviceId} for current alarms and notifications
• POST /devices/casestatus/{deviceId} for the physical enclosure state
• GET /devices/ping/{deviceId} for connectivity checks

For example:

curl --fail-with-body \
  "https://api.memo.wirewire.de/v1/devices/events/$DEVICE_ID" \
  --header "Accept: application/json" \
  --header "x-api-key: $MEMO_API_KEY"

Device commands

The API also exposes endpoints to register, reset, reboot, and change the LED state of a device. These are operational commands, not ordinary record updates.

Before calling one:

1. Verify the device belongs to the intended patient.
2. Confirm its most recent state and event history.
3. Require an explicit operator action for reset or reboot.
4. Prevent duplicate submissions while a command is in flight.
5. Record the actor, device ID, request time, and result without logging credentials or patient data unnecessarily.

Do not poll command endpoints. Use read endpoints for monitoring and apply backoff to repeated connectivity checks.