Managing a small device fleet with an intuitive device management interface is straightforward. But when you're overseeing hundreds or thousands of devices across locations, apps, and configurations, you might need something that goes beyond UI-based management. That's where APIs come in. For these enterprise-scale Esper Device Management customers, APIs aren’t a supplement for the console, they are the interface. 

These customers don't see API access as a nice-to-have, they’re API first, describing APIs as the primary way they work with Esper. One customer put it plainly: "99.99% you can do through the API." Another: "We're very API focused, so everything is pretty much an API." 

So what is API-first device management, and how does it work with Esper? We’ll dive in, starting with a quick primer on APIs and how they work within the Esper ecosystem. 

What is API-first Device Management?

An API (Application Programming Interface) is a way for software systems to talk to each other. Instead of logging into a console and clicking through menus, you send a request directly to the platform and get a response back. That response might include device data, confirm that a command was sent, or return the status of an app installation.

The Esper API lets you programmatically control and monitor provisioned devices with Esper. Common uses include observing device information and console activity, installing and updating apps, uploading files, and sending files to devices. Teams have also used it to automate app updates, perform bulk actions across device groups, and integrate Esper data into their own dashboards and workflows.

If you can do it in the Esper console, there's a good chance you can do it through the API — and often much faster, at much greater scale.

How Esper Customers Use Our APIs

Need inspiration for your first API-driven workflow? Our customers also build tooling to automate and scale these workflows. 

Some of the most common use cases we see:

• Automated app management: pushing updates, installing apps across device groups, and managing version control without manual intervention
• Device monitoring and reporting:  pulling device status, telemetry, and activity data into internal dashboards or alerting systems
• Provisioning at scale: using blueprint APIs to configure new devices automatically, reducing or eliminating manual setup steps
• Integration with internal tools: connecting Esper to ticketing systems, asset management platforms, and deployment pipelines

The recurring theme is scale. A task that takes two minutes per device in the console takes two seconds per device through the API. You can even use a cron job to run it unattended overnight.

Now that you know what customers are doing, let’s dive into the basics of the Esper API. 

The Basics of API-First Device Management

If you're new to the Esper API, here's what you need to make your first request: an API key, your Enterprise ID, and either cURL or Postman.

1. Generate an API key. In your Esper console, go to API Key Management and create a key. Treat it like a password and never share it publicly or commit it to a code repository.

2. Find your Enterprise ID. This also lives in the API Key Management screen. You'll need it as part of the URI for most requests.

3. Construct your request. Every Esper API request is made up of a REST verb (GET, POST, PUT, PATCH, or DELETE), a URI built from your tenant name and Enterprise ID, your authorization header, and any parameters or body content the endpoint requires. A basic request to list the devices in your tenant looks like this:

curl -X GET \

  https://{tenant_name}-api.esper.cloud/api/enterprise/{enterprise_id}/device/ \

  -H 'Authorization: Bearer {api_key}' \

  -H 'Content-Type: application/json'

4. Read the response. A successful request returns a JSON response with device data, status information, confirmation of an action, and so on. If something looks off, check the error reference for common status codes.

For a deeper walkthrough, including Postman instructions and exercises to practice constructing requests, see the full Getting Started with APIs guide.

Commands APIs: A Window into Esper's Evolution

Once you get started, you’ll start to discover that being truly API-first isn't just about coverage and tooling. It's also about architecture. Let’s take a moment to see how Esper architecture influences the API.  

One of the most powerful parts of the API is the command endpoints. Commands are how you tell devices to do things: reboot, lock the screen, install an app, wipe a device, push a configuration change. For teams managing fleets programmatically, commands are integral for day-to-day operations.

Commands V2 supports Android devices and represents our older architecture. 

Command Request is our newest architecture. As Esper has grown to support iOS, Windows, and other platforms under a single pane of glass, the commands infrastructure evolved with it, and can be used to build multi-OS workflows.

For the full list of available commands, request bodies, and required arguments, see the Creating API Commands guide in the help center.

Learn More: Esper API and SDK >

What’s Next?

The Esper API endpoints are how teams build, automate, and scale their device management workflows. Whether you're just getting started or looking to deepen an existing integration, understanding the architecture behind it helps you make better decisions about how — and what — to build. With API-first device management, you have full control to build reliable command-driven workflows across platforms.