The most common feedback we hear from customers who adopt the Esper API isn't about a specific endpoint. It's about a feeling: the moment a workflow that used to take hours becomes something that runs unattended overnight.
That feeling almost always comes from the same three capabilities: blueprints, converge, and automated app updates. Together, they form the backbone of what it actually means to manage devices at scale programmatically.
Using Blueprints to Set Baselines and Manage Programatically
A blueprint is Esper's way of defining the desired state for a device or group of devices. It contains which apps are installed, what settings are applied, and how the device behaves, in a single, versioned configuration object. Instead of configuring devices one at a time in the console, you define the configuration once and apply it broadly.
Blueprints work across Android, Apple, Windows, and Linux device management. One blueprint can encode the complete setup for a device type in your fleet, and any changes to that blueprint can be pushed to every assigned device.
The Blueprints API lets you create, retrieve, update, and manage blueprints programmatically. That means blueprint management can live inside your existing tooling, including your CI/CD pipeline, your deployment scripts, or your internal platform.
Learn More: Device Management for the Enterprise Edge >
Enforcing consistency with device converge
Publishing a new blueprint version doesn't automatically update the devices assigned to it. That's where converge comes in.
Converge is the operation that compares a device's current state to its assigned blueprint and brings it into alignment. It's how changes actually reach devices — pushing updated app versions, applying new settings, correcting configuration drift.
You can trigger a converge via the Commands API or Operations API.
Commands API
When converging a device or group of devices, use the Commands API.
POST https://{tenant_name}-api.esper.cloud/api/commands/v0/commands/
{
"command_type": "DEVICE",
"devices": ["device_id"],
"device_type": "all",
"command": "CONVERGE"
}
Converge also works at the group level: swap "command_type": "GROUP" and replace the devices array with a groups array to push changes to an entire fleet segment at once. That's where the real leverage is.
Operations API
For very large operations (we’re talking about thousands of devices) use the optimized Operations endpoints.
POST https://{tenant}-api.esper.cloud/api/v0/operations/{
"operation_type":"CONVERGE",
"arguments":{},
"schedule_type":"IMMEDIATE",
"operation_device_query": {
"device_ids":"device_id_1, device_id_2,...., device_id_50000"
}
}
Operations works with smaller deployments as well, but you’ll need to track Operations APIs from the Activity Feed rather than the Event Feed.
Automating app updates with APIs
One of the most immediately useful things you can do with the Esper API is automate enterprise app updates. Normally, pushing a new app version means uploading it in the console, updating the blueprint, and converging. This sequence works for operators managing single locations, but what happens when you have to update at the regional or national level?
Read More: API-first Device Management >
With the API, that entire sequence becomes a script. Here's the general flow:
Step 1: Upload the new app version
POST https://{tenant_name}-api.esper.cloud/api/enterprise/{enterprise_id}/application/upload/
Submit the APK as multipart/form-data. The response gives you the new application_id and version_id.
Step 2: Get the target blueprint and retrieve its current settings
GET https://{tenant_name}-api.esper.cloud/api/v2/blueprints/
Parse the response for the blueprint you want to update. Pull the id and the full settings.android block (or the OS you’re working with). Then you'll need both to write back the changes.
Step 3: Add the new app version to the blueprint
Modify the apps section of the settings object with the new app_id and app_version_id from Step 1, then save:
PUT https://{tenant_name}-api.esper.cloud/api/v2/blueprints/{blueprint_id}/
{
"publish": true,
"settings": { "android": { ...updated settings... } }
}
Setting "publish": true makes the updated blueprint version live immediately. A draft version ("publish": false) lets you stage changes for review first.
Step 4: Converge to devices
POST https://{tenant_name}-api.esper.cloud/api/commands/v0/commands/
{
"command_type": "GROUP",
"groups": ["{group_id}"],
"device_type": "all",
"command": "CONVERGE"
}
The full Python implementation of this workflow — including error handling and step-by-step breakdown — is in the Automating App Updates guide.
Applying Automations to Your Device Management Workflow
Save time across every update you ever push. That could translate to countless hours and effort in the long run.
Once the workflow exists, an app update is no longer a manual task. A new build can trigger an upload, a blueprint update, and a group-wide converge. Best yet, you can integrate this workflow into your own systems because it’s entirely API-based.
Teams managing hundreds or thousands of devices can operate with the same efficiency as teams managing dozens. And because blueprints track every change as a versioned record, there's a built-in audit trail. You can see exactly what changed, when, and roll back if something goes wrong.
These are workflows a small engineering team can build in an afternoon using standard tools and the Esper API. The APIs are REST-based, the documentation includes working code examples, and the logic maps directly to operations your team already understands: upload, configure, deploy. Whether you're integrating Esper into a CI/CD pipeline, an internal platform, or a set of scheduled scripts, the building blocks are straightforward.
For organizations managing device fleets at scale, that kind of automation isn't a nice-to-have. It's what makes the whole operation sustainable.
Ready to start building? Start your Esper Free Trial, then check out the Esper API reference and the Getting Started with APIs guide.
.png)
