Esper Foundation Foundry Builds API

openapi: 3.2.0
info:
  title: ESPER API REFERENCE Foundation Foundry Builds API
  x-logo:
    url: esper-logo-white.svg
    backgroundColor: '#141418'
    altText: Logo
  description: '# Introduction

    Welcome to Esper’s API documentation. The Esper API allows users to accomplish operations outside of the console. Some common uses for our APIs include observing device information and console activity, installing and updating apps, uploading files, and sending files to devices. Our users have also used the API to automate app updates, perform bulk actions, and more. Esper API endpoints use REST-based architecture and return JSON responses. See our documentation for:


    * Getting started guides

    * Commonly used API examples

    * API command examples

    * Automated Script examples

    * And more


    # Authentication


    You need to create an API Key to interact with our APIs. Learn more about generating an API Key. You can also learn more about Esper and sign up for an account at esper.io/signup. Some endpoints also require an Enterprise ID. This ID can be found in the API Management section of the Esper console. # Lifecycle Labels


    Esper uses lifecycle labels to communicate the support status of each API endpoint. Use the following table to understand what each label means and how to respond. Badge

    What it means

    Recommended action


    Stable

    This endpoint is fully supported and safe for production use. No action needed. Beta

    This endpoint is publicly available but may change. It is not recommended for production integrations. Use with caution. Monitor the API changelog for updates before relying on this endpoint. Legacy

    This endpoint uses an older architecture and is still supported, but a newer equivalent exists. It is not recommended for new integrations. Plan migration to the recommended replacement when possible. See the endpoint description for the alternative. Deprecated

    This endpoint has stopped being supported. A removal date may be added at a later time. A replacement is available or the feature is entirely retired. Migrate before the removal date listed in the endpoint description. Do not use this endpoint in new integrations. # Pagination


    Responses may be paginated. Use the following parameters to query the data. A full list of parameters can be found on the endpoint’s documentation page. Parameter

    Data Type

    Explanation


    limit

    integer

    Limit the data returned. Default = 20. offset

    integer

    Offset to the first item returned. Default = 0. ordering

    string

    Order the results set by the field name. Varies by endpoint. next

    string

    Paginate to the next response set. previous

    string

    Paginate to the last set response. # Errors

    We use standard HTTP status codes for success or failure. A typical error response may look something like this:


    ```json

    {

    "errors": [],

    "message": "error message",

    "status": 400

    }

    ```

    * `errors` - List of error details

    * `message` - Error description

    * `status` - HTTP status code


    Some common status codes and messages are:


    Number

    Message

    Explanation


    200

    OK

    The request succeeded. 201

    Resource creation

    A resource was created. 401

    Unauthorized

    The API key is invalid. 404

    Not found

    The resource was not found. 429

    Rate limit exceeded

    Too many requests. Wait a moment and try again. 500

    Server error

    Internal error. Wait a moment and try again. If the issue persists, contact Esper. See how our systems are doing by checking our status page. # Rate Limits

    To ensure quality of service for all customers, we enforce rate limits for API requests. Most customers won’t hit this limit with normal use. In case you experience 429 or rate limit exceeded errors, we recommend the following:

    * Try sending requests in batches. * Begin with about 20 requests at a time and building up from there. * Ensure your scripts are efficient and don’t contain redundant calls. * Reach out to your account manager to discuss your options.'
  termsOfService: https://esper.io/terms-of-service
  contact:
    email: developer@esper.io
  license:
    name: Apache 2.0
    url: http://www.apache.org/licenses/LICENSE-2.0.html
  version: 1.0.0
  x-prefix-tag: esper cloud api
servers:
- url: https://{foo}-api.esper.cloud/api
  variables:
    foo:
      default: develop
      description: Custom end point
tags:
- name: foundation_FoundryBuilds
  x-displayName: FoundryBuilds
paths:
  /v1/foundry/builds/:
    get:
      summary: Get Foundry builds
      description: 'Returns a deduplicated list of all Esper Foundation OS version strings currently present across enrolled devices in the tenant.


        Use this endpoint to inventory which Foundation OS versions are deployed across your fleet — useful for identifying version spread, spotting devices running outdated builds, and scoping update operations.


        **About Get All Distinct Foundation Versions**


        Esper Foundation is a customized Android-based operating system for x86 and ARM devices, providing long-term support, regular security patches, and broad hardware compatibility. Foundation version strings follow the format [Android version].[Major Foundation version].[Minor Foundation version].[Build version] — for example, 7.10.21.02 indicates Android 7, Major Foundation version 10, Minor version 21, build 02. This endpoint returns each distinct version once regardless of how many devices share it, giving a fleet-wide view of OS version distribution. It requires the read:foundationversions scope.


        **Key Fields / Query Parameters**


        search — Partial string match (case-insensitive) to filter returned version strings


        limit — Number of results per page; defaults to 10


        offset — Starting index for pagination


        foundation_version — The version string returned per result, in [Android].[Major].[Minor].[Build] format


        **Common Use Cases**


        Auditing Foundation OS version spread across a fleet before planning an update campaign


        Identifying whether devices running builds below a minimum supported version are present in the tenant


        Cross-referencing deployed versions against the latest approved builds visible in Esper Software Updates for Foundation


        **Best Practices**


        Use search to quickly check whether a specific Foundation version is present rather than paginating the full list


        Combine results with device list endpoints filtered by Foundation version to enumerate specific devices on a given OS version


        Call this before scheduling OTA operations to establish a version distribution baseline


        **Workflow**


        Call GET /api/v2/foundationversions to retrieve all distinct Foundation OS versions present in the tenant


        Compare results against the latest approved build in Esper Software Updates for Foundation to identify outdated versions


        Use device list endpoints filtered by Foundation version to target devices on older builds for update via Pipeline, auto-update, or API-based FOTA'
      security:
      - foundation_AuthToken: []
      operationId: getFoundryBuilds
      tags:
      - foundation_FoundryBuilds
      parameters:
      - in: query
        name: foundation_major_number
        description: Filter by Esper Foundation Major Number, Foundation Numbers are integers starting at 1.
        schema:
          type: string
      - in: query
        name: build_arch
        description: Filter by build architecture name, build architectures {arm, arm64, x86_64, x86}
        schema:
          type: string
      - in: query
        name: android_major_version
        description: Filter by Android Major Version, Android Major Versions are integers starting at 1 and going to Current Android Release
        schema:
          type: integer
      - in: query
        name: device_model_id
        description: Device model id
        schema:
          type: string
          format: uuid
      - in: query
        name: approved
        description: Filter builds which have been approved for OTA update
        schema:
          type: boolean
      - in: query
        name: limit
        schema:
          type: integer
      - in: query
        name: offset
        schema:
          type: integer
      - in: query
        name: ordering
        schema:
          type: string
      - in: query
        name: locked
        description: Filter the locked builds. To be used with build_fingerprint_hash and device_model_id
        schema:
          type: boolean
      - in: query
        name: build_fingerprint_hash
        description: hash of the build fingerprint of the existing build
        schema:
          type: string
      responses:
        '200':
          description: List of Foundry builds
          content:
            application/json:
              schema:
                type: object
                properties:
                  code:
                    type: integer
                    description: returned response code
                  content:
                    properties:
                      count:
                        type: integer
                        description: counter of number of builds retrieved
                      next:
                        type: string
                        format: url
                        description: url of the next ten builds
                      previous:
                        type: string
                        format: url
                        description: url of the previous ten builds
                      results:
                        items:
                          $ref: '#/components/schemas/foundation_Build_V1'
        '401':
          description: Unauthorized
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/foundation_Error_401_Unauthorized'
        '500':
          description: Internal server error
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/foundation_Error_500_Internal_Server_Error'
  /v1/foundry/builds/{build_id}/:
    get:
      summary: Get Foundry Build
      description: 'Returns a paginated list of Foundation OS builds registered in the Foundry system, with filters for architecture, Android version, device model, approval status, and more.


        Use this endpoint to browse available Foundation builds for a specific device model — for example, to find all approved builds before initiating a Pipeline deployment or configuring auto-update.


        **About Get Foundry Builds**


        Foundry is Esper''s build management backend for Foundation OS. Each Foundry build represents a compiled OS image tied to a specific device model, CPU architecture, and Foundation version. Builds go through a lifecycle — released, to_be_deprecated, or unavailable — and must be explicitly approved before they can be used for OTA deployment or auto-update. The Console surfaces these builds in the Esper Software Updates > Esper Foundation tab; this endpoint provides the same catalog programmatically.


        **Key Fields / Query Parameters**


        foundation_major_number — Filter by Foundation major version number (integer starting at 1)


        build_arch — Filter by CPU architecture: arm, arm64, x86, or x86_64


        android_major_version — Filter by Android major version (integer)


        device_model_id — Filter builds for a specific device model (UUID)


        approved — When true, returns only builds approved for OTA deployment


        locked — Filter for builds currently locked to a device model; use with build_fingerprint_hash and device_model_id


        build_fingerprint_hash — Hash of an existing build''s fingerprint, used to identify a currently installed build


        build_state — Lifecycle status: released, to_be_deprecated, or unavailable


        **Common Use Cases**


        Listing all approved Foundation builds for a device model before scheduling a Pipeline deployment or enabling auto-update


        Auditing available builds by architecture and Android version across supported hardware


        Identifying builds approaching deprecation (to_be_deprecated) to plan timely update campaigns


        **Best Practices**


        Always filter by approved=true when looking for builds eligible for deployment — unapproved builds cannot be used for OTA or auto-update


        Filter by device_model_id to scope results to your target hardware, since builds are model-specific


        Monitor build_state values and proactively migrate devices off to_be_deprecated builds before they become unavailable


        Workflow


        Call GET /v1/foundry/builds/ with device_model_id and approved=true to list eligible builds for your target hardware


        Review build_arch, foundation_major_number, and android_major_version to identify the desired build


        Use the returned build_id to approve the build (PUT /v1/foundry/builds/{build_id}/) or lock it for auto-update (PUT /v1/foundry/device-models/{device_model_id}/)'
      security:
      - foundation_AuthToken: []
      tags:
      - foundation_FoundryBuilds
      parameters:
      - name: build_id
        in: path
        description: A build UUID specifying the Foundry Build
        required: true
        schema:
          type: string
      responses:
        '200':
          description: Specified Foundry build
          content:
            application/json:
              schema:
                type: object
                properties:
                  content:
                    $ref: '#/components/schemas/foundation_Build_V1'
        '401':
          description: Unauthorized
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/foundation_Error_401_Unauthorized'
        '404':
          description: Build not found
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/foundation_Error_404_Not_Found'
        '500':
          description: Internal server error
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/foundation_Error_500_Internal_Server_Error'
      operationId: getV1FoundryBuildsByBuildId
      x-operation-id-source: derived
    put:
      summary: Update Foundry build
      description: 'Retrieves full details for a single Foundation OS build by its unique Foundry build ID.


        Use this endpoint to inspect a specific build''s metadata — including its architecture, Foundation version numbers, Android SDK level, approval status, and lifecycle state — before approving it or locking it to a device model for auto-update.


        **About Get Foundry Build**


        Foundry builds are the individual compiled OS images that make up the Foundation update catalog. Each build is identified by a UUID (build_id) and carries detailed metadata about the OS it contains: Foundation major/minor/build version numbers, Android version, CPU architecture, build hash, and whether it has been approved for OTA deployment. This endpoint returns the full Build_V1 object for a single build, providing the complete picture needed for approval or deployment decisions.


        Key Fields / Query Parameters


        build_id (path, required) — UUID of the Foundry build to retrieve


        foundation_major_number / foundation_minor_number / foundation_build_number — Foundation version components of the build


        android_major_version / android_sdk_level — Android version metadata


        build_arch — CPU architecture (arm, arm64, x86, x86_64)


        approved — Whether the build has been approved for OTA deployment


        build_state — Lifecycle status: released, to_be_deprecated, or unavailable


        deprecated_on — Date the build was or will be deprecated


        release_notes — JSON-formatted release notes for the build


        **Common Use Cases**


        Confirming a build''s approval status and lifecycle state before using its build_id in a device model auto-update configuration


        Reviewing release notes and version metadata for a specific build ahead of a planned deployment


        Retrieving build details to display in internal tooling or audit records


        **Best Practices**


        Always check approved and build_state before proceeding with deployment — only approved: true builds in released state are safe to deploy


        Store the build_fingerprint_hash if you need to identify this build later via the list endpoint''s locked filter


        Review deprecated_on to understand the support window remaining for this build


        **Workflow**


        Obtain a build_id from GET /v1/foundry/builds/ filtered by device model and architecture


        Call GET /v1/foundry/builds/{build_id}/ to confirm approval status, version details, and release notes


        Proceed to PUT /v1/foundry/builds/{build_id}/ to approve the build, or PUT /v1/foundry/device-models/{device_model_id}/ to lock it for auto-update'
      security:
      - foundation_AuthToken: []
      operationId: updateFoundryBuild
      tags:
      - foundation_FoundryBuilds
      parameters:
      - name: build_id
        in: path
        description: A build UUID specifying the Foundry Build
        required: true
        schema:
          type: string
      requestBody:
        required: true
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/foundation_Foundry_Build_PUT_Request_V1'
      responses:
        '200':
          description: Updated
          content:
            application/json:
              schema:
                type: object
                properties:
                  data:
                    $ref: '#/components/schemas/foundation_Build_V1'
        '400':
          description: Bad Request
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/foundation_Error_400_Bad_Data'
        '401':
          description: Unauthorized
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/foundation_Error_401_Unauthorized'
        '404':
          description: Builds not found
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/foundation_Error_404_Not_Found'
components:
  schemas:
    foundation_Foundry_Build_PUT_Request_V1:
      type: object
      properties:
        approve:
          type: boolean
        user_remarks:
          type: string
    foundation_Error_500_Internal_Server_Error:
      type: object
      properties:
        code:
          type: integer
          format: int32
          default: 500
        message:
          type: string
        content:
          type: object
      required:
      - code
      - message
    foundation_Error_401_Unauthorized:
      type: object
      properties:
        code:
          type: integer
          format: int32
          default: 401
        message:
          type: string
        content:
          type: object
      required:
      - code
      - message
    foundation_Error_400_Bad_Data:
      type: object
      properties:
        code:
          type: integer
          format: int32
          default: 400
        message:
          type: string
        content:
          type: object
      required:
      - code
      - message
    foundation_Build_V1:
      type: object
      properties:
        build_id:
          type: string
        created_at:
          type: string
          format: date-time
        updated_at:
          type: string
          format: date-time
        deprecated_on:
          type: string
          format: date-time
        created_by:
          type: string
        updated_by:
          type: string
        ab_update:
          type: boolean
        android_major_version:
          type: integer
        android_minimum_sdk_level:
          type: integer
        android_minor_version:
          type: string
        android_sdk_level:
          type: integer
        build_arch:
          type: string
        build_flavor:
          type: string
        build_hash:
          type: string
        build_ota_hash:
          type: string
        build_job_url:
          type: string
        build_job_id:
          type: integer
        build_fingerprint_hash:
          type: string
        build_type:
          type: string
        build_url:
          type: string
          format: url
        build_update_meta_data:
          type: string
          format: json
        build_update_url:
          type: string
          format: url
        file_size_kb:
          type: integer
        foundation_build_number:
          type: integer
        foundation_major_number:
          type: integer
        foundation_minor_number:
          type: integer
        foundation_name:
          type: string
        model_display_name:
          type: string
        build_job_params:
          type: string
          format: json
        prebuilt_app_info:
          type: string
          format: json
        release_notes:
          type: string
          format: json
        release_rating:
          type: string
        source_build_id:
          type: string
        build_state:
          type: string
          enum:
          - released
          - to_be_deprecated
          - unavailable
        device_model_id:
          type: string
        approved:
          type: boolean
    foundation_Error_404_Not_Found:
      type: object
      properties:
        code:
          type: integer
          format: int32
          default: 404
        message:
          type: string
        content:
          type: object
      required:
      - code
      - message
  securitySchemes:
    esper_cloud_api_apiKey:
      type: http
      scheme: bearer
      description: "#### API KEY - Access Token\nAccess token for API is passed as authorization header in calls. You need to generate this from your Esper Console at `<domain>-api.esper.cloud` where foo is the sub-domain name you gave for your Esper Dev environment when you signed up for your Esper account. Please follow the instructions [in this Help article](https://help.esper.io/hc/en-us/articles/12656959508497) to generate an access token.\nOnce you have the access token, you need to send an authorization header as below\n\n```bash\n\n    curl -X GET \\\n      https://<domain>-api.esper.cloud/api/enterprise/<enterprise_id>/device/ \\\n      -H 'Authorization: Bearer <ACCESS_TOKEN>' \\\n      -H 'Content-Type: application/json' \\\n```\n\n> Please note the use of keyword **Bearer** before the token value.\n\n\nYou can read more about api key authentication [here](https://help.esper.io/hc/en-us/articles/12656959508497).\n"
    pipelines_SCAPIAuthToken:
      type: http
      scheme: bearer
    device_apiKey:
      type: http
      scheme: bearer
      description: "#### API KEY - Access Token\nAccess token for API is passed as authorization header in calls. You need to generate this from your Esper Console at `<domain>-api.esper.cloud` where foo is the sub-domain name you gave for your Esper Dev environment when you signed up for your Esper account. Please follow the instructions [in this Help article](https://help.esper.io/hc/en-us/articles/12656959508497) to generate an access token.\nOnce you have the access token, you need to send an authorization header as below\n\n```bash\n\n    curl -X GET \\\n      https://<domain>-api.esper.cloud/api/enterprise/<enterprise_id>/device/ \\\n      -H 'Authorization: Bearer <ACCESS_TOKEN>' \\\n      -H 'Content-Type: application/json' \\\n```\n\n> Please note the use of keyword **Bearer** before the token value.\n\n\nYou can read more about api key authentication [here](https://help.esper.io/hc/en-us/articles/12656959508497).\n"
    apps_management_apiKey:
      type: http
      scheme: bearer
      description: "#### API KEY - Access Token\nAccess token for API is passed as authorization header in calls. You need to generate this from your Esper Console at `<domain>-api.esper.cloud` where foo is the sub-domain name you gave for your Esper Dev environment when you signed up for your Esper account. Please follow the instructions [in this Help article](https://help.esper.io/hc/en-us/articles/12656959508497) to generate an access token.\nOnce you have the access token, you need to send an authorization header as below\n\n```bash\n\n    curl -X GET \\\n      https://<domain>-api.esper.cloud/api/enterprise/<enterprise_id>/device/ \\\n      -H 'Authorization: Bearer <ACCESS_TOKEN>' \\\n      -H 'Content-Type: application/json' \\\n```\n\n> Please note the use of keyword **Bearer** before the token value.\n\n\nYou can read more about api key authentication [here](https://help.esper.io/hc/en-us/articles/12656959508497).\n"
    commands_apiKey:
      type: http
      scheme: bearer
      description: "#### API KEY - Access Token\nAccess token for API is passed as authorization header in calls. You need to generate this from your Esper Console at `<domain>-api.esper.cloud` where foo is the sub-domain name you gave for your Esper Dev environment when you signed up for your Esper account. Please follow the instructions [in this Help article](https://help.esper.io/hc/en-us/articles/12656959508497) to generate an access token.\nOnce you have the access token, you need to send an authorization header as below\n\n```bash\n\n    curl -X GET \\\n      https://<domain>-api.esper.cloud/api/enterprise/<enterprise_id>/device/ \\\n      -H 'Authorization: Bearer <ACCESS_TOKEN>' \\\n      -H 'Content-Type: application/json' \\\n```\n\n> Please note the use of keyword **Bearer** before the token value.\n\n\nYou can read more about api key authentication [here](https://help.esper.io/hc/en-us/articles/12656959508497).\n"
    drift_apiKey:
      type: http
      scheme: bearer
      description: "#### API KEY - Access Token\nAccess token for API is passed as authorization header in calls. You need to generate this from your Esper Console at `<domain>-api.esper.cloud` where foo is the sub-domain name you gave for your Esper Dev environment when you signed up for your Esper account. Please follow the instructions [in this Help article](https://help.esper.io/hc/en-us/articles/12656959508497) to generate an access token.\nOnce you have the access token, you need to send an authorization header as below\n\n```bash\n\n    curl -X GET \\\n      https://<domain>-api.esper.cloud/api/enterprise/<enterprise_id>/device/ \\\n      -H 'Authorization: Bearer <ACCESS_TOKEN>' \\\n      -H 'Content-Type: application/json' \\\n```\n\n> Please note the use of keyword **Bearer** before the token value.\n\n\nYou can read more about api key authentication [here](https://help.esper.io/hc/en-us/articles/12656959508497).\n"
    device_onboarding_apiKey:
      type: http
      scheme: bearer
      description: "#### API KEY - Access Token\nAccess token for API is passed as authorization header in calls. You need to generate this from your Esper Console at `<domain>-api.esper.cloud` where foo is the sub-domain name you gave for your Esper Dev environment when you signed up for your Esper account. Please follow the instructions [in this Help article](https://help.esper.io/hc/en-us/articles/12656959508497) to generate an access token.\nOnce you have the access token, you need to send an authorization header as below\n\n```bash\n\n    curl -X GET \\\n      https://<domain>-api.esper.cloud/api/enterprise/<enterprise_id>/device/ \\\n      -H 'Authorization: Bearer <ACCESS_TOKEN>' \\\n      -H 'Content-Type: application/json' \\\n```\n\n> Please note the use of keyword **Bearer** before the token value.\n\n\nYou can read more about api key authentication [here](https://help.esper.io/hc/en-us/articles/12656959508497).\n"
    tenant_apiKey:
      type: http
      scheme: bearer
      description: "#### API KEY - Access Token\nAccess token for API is passed as authorization header in calls. You need to generate this from your Esper Console at `<domain>-api.esper.cloud` where foo is the sub-domain name you gave for your Esper Dev environment when you signed up for your Esper account. Please follow the instructions [in this Help article](https://help.esper.io/hc/en-us/articles/12656959508497) to generate an access token.\nOnce you have the access token, you need to send an authorization header as below\n\n```bash\n\n    curl -X GET \\\n      https://<domain>-api.esper.cloud/api/enterprise/<enterprise_id>/device/ \\\n      -H 'Authorization: Bearer <ACCESS_TOKEN>' \\\n      -H 'Content-Type: application/json' \\\n```\n\n> Please note the use of keyword **Bearer** before the token value.\n\n\nYou can read more about api key authentication [here](https://help.esper.io/hc/en-us/articles/12656959508497).\n"
    foundation_AuthToken:
      type: apiKey
      in: header
      name: Authorization
    reports_bearerAuth:
      type: http
      scheme: bearer
    geofence_bearerAuth:
      type: http
      scheme: bearer
      bearerFormat: JWT
x-tagGroups:
- name: ESPER CLOUD API
  tags:
  - esper_cloud_api_Company Settings
  - esper_cloud_api_Application
  - esper_cloud_api_Application V1
  - esper_cloud_api_AndroidDevice
  - esper_cloud_api_Device Group
  - esper_cloud_api_Token (Deprecated)
  - esper_cloud_api_Commands V2
  - esper_cloud_api_Enterprise Policy
  - esper_cloud_api_Geofence
  - esper_cloud_api_Content
  - esper_cloud_api_User (Deprecated)
  - esper_cloud_api_User
  - esper_cloud_api_Blueprint (Deprecated)
  - esper_cloud_api_Directory Record
  - esper_cloud_api_Tile Icon
  - esper_cloud_api_Alerts
  - esper_cloud_api_Alarms
  - esper_cloud_api_Wallpapers
  - esper_cloud_api_Device Telemetry
  - esper_cloud_api_Daily and Custom Reports
  - esper_cloud_api_SSO Connections
  - esper_cloud_api_Roles
  - esper_cloud_api_Personal Access Token
- name: BLUEPRINTS
  tags:
  - blueprints_Blueprints API
  - blueprints_Custom Actions API
  - blueprints_Background Scripts API
- name: PIPELINES
  tags:
  - pipelines_System Status Code
  - pipelines_System
  - pipelines_Pipelines
  - pipelines_Stages
  - pipelines_Target Lists
  - pipelines_Targets
  - pipelines_Device Groups
  - pipelines_Operation Lists
  - pipelines_Operations
  - pipelines_Pipeline Runs
  - pipelines_Stage Runs
  - pipelines_Target Runs
- name: DEVICE
  tags:
  - device_Device
  - device_Device Heartbeat
  - device_Device Apps
  - device_Device Enrollment in EMM
  - device_Operations
  - device_DeviceOperations
  - device_MultiOS Remote Viewer
- name: APPS MANAGEMENT
  tags:
  - apps_management_VPP License Management
  - apps_management_VPP App Management
  - apps_management_Tenant Apps
  - apps_management_Apple App Store
  - apps_management_App List
  - apps_management_Webclips
  - apps_management_Provisioning Profiles
  - apps_management_Preferred Regions
  - apps_management_OEM Config Schema
  - apps_management_Esper Apps
  - apps_management_Tenant Esper Apps
- name: COMMANDS
  tags:
  - commands_Command Request
  - commands_Command Status
- name: DRIFT
  tags:
  - drift_Converge
  - drift_Converge Command
  - drift_Blueprint Drift
- name: DEVICE ONBOARDING
  tags:
  - device_onboarding_DEP Sync Request
  - device_onboarding_ABM Provisioning
- name: TENANT
  tags:
  - tenant_APNs certificate
  - tenant_DEP Profile
  - tenant_DEP Tokens
  - tenant_VPP Token Management
  - tenant_Google Enterprise
  - tenant_MDM Service Config
- name: FOUNDATION
  tags:
  - foundation_FoundryBuilds
  - foundation_FoundryDeviceModels
  - foundation_FoundryEvents
- name: REPORTS
  tags:
  - reports_Reports API
- name: GEOFENCE
  tags:
  - geofence_Geofences
  - geofence_Device State
x-provenance:
  method: harvested
  publisher: Esper
  source: https://api.esper.io/_bundle/openapi.json?download
  note: split by refine-openapis from the provider's own published document, verified by fetch (openapi/_original/*.fetch.json);
    stamped by stamp-openapi-provenance.py (roadmap#793)