Deployment Manager

The Deployment Manager API lets you monitor and manage your Roboflow Device Manager (RFDM) devices programmatically.

All endpoints are mounted under /:workspace/devices/v2 on the public API host (https://api.roboflow.com). Read endpoints require a scoped API key with the device:read scope; the create endpoint requires device:update. Workspace API keys with no explicit scopes list are implicitly granted all scopes (legacy behavior); keys that carry an explicit scopes array must include the relevant scope.

With the Deployment Manager API, you can:

Authentication

All endpoints accept a workspace API key via either:

  • Query string: ?api_key=YOUR_API_KEY

  • Header: Authorization: Bearer YOUR_API_KEY

Device-scoped API keys

API keys minted for a specific device (for example, by RFDM during install) are narrowed to that device. They may only call routes whose :deviceId path parameter equals the key's bound device. They will receive 403 on the workspace-wide list and create endpoints, and on any :deviceId path that doesn't match.

Cross-workspace isolation

A workspace API key can only read or modify devices that belong to its workspace. Requests for a device id owned by a different workspace return 404, even if the id is otherwise valid.

Errors

Status
Meaning

400

Invalid query parameter (unknown time_period, malformed cursor or date, invalid direction, etc.) or invalid request body.

401

Missing or invalid API key.

403

Device-scoped API key targeting a different device, the workspace-wide list/create routes, a source device from another workspace during duplication, or a feature-gated request rejected (for example, AI1 creation or offline_mode not enabled for the workspace).

404

Device, stream, config, or source device not found. Read requests for device ids owned by another workspace also return 404.

429

Rate limit exceeded. Logs are limited to 5 requests per minute per IP and 50 per minute globally; telemetry reads are limited to 60 requests per minute per device with a 10-request burst over 10 seconds.

Error responses use one of two shapes:

  • Handler-level errors (typically 400, 403, 404, and 429 from the handlers themselves) return { "error": "<message>" }.

  • Authentication and workspace-validation failures (typically 401) return a structured error object: { "error": { "message": "...", "status": 401, "type": "OAuthException", "hint": "..." } }.

The logs rate limiter additionally returns a plain string body (not JSON) when it triggers a 429.

Last updated

Was this helpful?