Changelog

2026-10-18: Device status, screen time and app usage

New endpoints for the operational status of a device and for the screen time and app usage of Windows devices, plus connectivity and more Windows details on every device. All changes are additive within v1.

New endpoints

• GET/v1/devices/{deviceId}/statusRetrieve a device’s status
• GET/v1/devices/{deviceId}/screen-timeList a device’s daily screen time
• GET/v1/devices/{deviceId}/app-usageList a device’s daily app usage

New fields

• connectivity on every device object, in GET /v1/devices, GET /v1/devices/{deviceId} and GET /v1/policies/{policyId}/devices. It reports online, offline or unknown from lastSeenAt.
• New Windows details, all scalar values: batteryLevel, batteryCharging, batteryReportedAt, managementMode, enrollmentType, lastMdmSessionAt, kioskStatus, kioskPaused, kioskLastVerifiedAt.
• The screen time and app usage list objects carry collection, which tells you whether the device’s policy collects usage.

New scope and error code

• usage:read grants the screen time and app usage endpoints. It is separate from devices:read because the data describes how people use their devices. Existing keys don’t have it. To use the new endpoints, create a key with usage:read.
• 422 unsupported_platform: the screen time and app usage endpoints return it for devices that are not Windows devices.

Changes to existing behavior

• On Windows, enrollment.enrolledAt was always null. It now holds the enrollment date. phoneNumber was always null and now holds the SIM number where the device has one.
• When reading the data for a request takes longer than WeGuard allows, any endpoint now returns 503 service_unavailable with Retry-After: 5 instead of 500 internal_error. Retry it with backoff.
• On the screen time and app usage endpoints, since and until are UTC calendar dates, both inclusive. Everywhere else they stay ISO-8601 timestamps. See Date ranges.

Documentation corrections

• state.lost is always false on Windows, which has no lost mode.
• The Windows details example now shows values as devices report them: totalStorage and totalRam are mebibyte strings such as "242935", and osEdition and processorArchitecture are numeric codes such as "48" and "9". Only the documentation changed: the API already returned these values.

2026-10-07: v1 released

First release of the WeGuard Developer API. It gives read-only access to devices on Android, iOS, macOS, tvOS and Windows, their installed apps and locations, policies, the account, its console users and the console audit log.

Endpoints

• Identity
  • GET/v1/meRetrieve the calling key
• Account
  • GET/v1/accountRetrieve the account
• Devices
  • GET/v1/devicesList devices
  • GET/v1/devices/{deviceId}Retrieve a device
  • GET/v1/devices/{deviceId}/locationRetrieve a device’s location
• Installed apps
  • GET/v1/devices/{deviceId}/appsList a device’s installed apps
• Location history
  • GET/v1/devices/{deviceId}/locationsList a device’s location history
• Policies
  • GET/v1/policiesList policies
  • GET/v1/policies/{policyId}Retrieve a policy
  • GET/v1/policies/{policyId}/devicesList a policy’s devices
• Users
  • GET/v1/usersList users
  • GET/v1/users/{userId}Retrieve a user
• Audit logs
  • GET/v1/audit-logsList audit log entries

Platform

• API keys with scopes (devices:read, apps:read, locations:read, policies:read, account:read, users:read, audit_logs:read). Account admins create them in the console, with an optional expiry, and can revoke them there. See Authentication.
• Cursor pagination with optional total counts. Event lists are filtered by time ranges and returned newest first.
• RFC 9457 problem details with stable error codes and request ids.
• Rate limits of 600 requests per minute per key, with RateLimit-* headers.
• ETags for conditional requests, and strict query parameter validation.
• An OpenAPI 3.1 description and a Postman collection of the whole API, for generating clients and trying requests. See OpenAPI and Postman.