What is the purpose of the GET Build Details endpoint?

It retrieves the full details of a single build, including its processing status, metadata, and platform-specific information. It's recommended for polling after upload until the build is processed or errors.

What are the two APIs available for retrieving build details?

Applivery provides the Integrations API (per-app) and the Workspace API (workspace-level) for retrieving build details.

When should I use the Integrations API to get build details?

Use the Integrations API for per-app integrations, CI/CD pipelines, and post-upload status polling. It uses an App API Token for authentication.

How do I authenticate with the Integrations API?

Authenticate using an App API Token in the `Authorization` header: `Authorization: Bearer `.

When should I use the Workspace API to get build details?

Use the Workspace API for workspace-level automation across multiple apps. It uses a Service Account token for authentication.

How do I authenticate with the Workspace API?

Authenticate using a Service Account token in the `Authorization` header: `Authorization: Bearer `.

What path parameters are required for the Workspace API?

The Workspace API requires `organizationId`, `applicationId`, and `buildId` in the path.

What does a 400 Bad Request error mean when getting build details?

A 400 error with code 5014 means the build exists but hasn't finished processing. Retry after a short delay.

Get Applivery Build Details via API

GET – Build Details

Returns the full details of a single build, identified by its buildId. This is the primary endpoint for inspecting the processing status, metadata, and platform-specific information of a specific build — and the recommended endpoint for polling after an upload until the build reaches a terminal state (processed or error).

Applivery provides two separate APIs for retrieving build details, each requiring a different authentication credential.

Choosing the Right API

	Integrations API	Workspace API
Designed for	Per-app integrations, CI/CD pipelines, post-upload status polling	Workspace-level automation across multiple apps
Authentication	App API Token (per-app)	Service Account token (workspace-level)
App context	Implicit — token is already scoped to an app	Explicit — `organizationId` and `applicationId` required in the path
Typical users	CI scripts checking if a build has finished processing	Platform engineers inspecting builds across multiple apps

Warning

Access to the different APIs might not be available in your current plan. Please check availability on our pricing page.

Integrations API

Use this endpoint when retrieving build details within the scope of a single app. Authentication uses an App API Token, scoped to the specific app.

To create an App API Token, see Apps API Authentication.

Endpoint

GET https://api.applivery.io/v1/integrations/builds/{buildId}

Authentication

Authorization: Bearer <your_app_token>

Path Parameters

Parameter	Type	Required	Description
`buildId`	String	Yes	The unique identifier of the build to retrieve. E.g. `552ae3cfcb5abfc58d733b81`. The `buildId` is returned in the response of POST – Upload a Build and GET – List of Builds.

Example Request

curl 'https://api.applivery.io/v1/integrations/builds/552ae3cfcb5abfc58d733b81' \
  -X GET \
  -H 'Authorization: Bearer YOUR_APP_TOKEN'

Responses

{
  "status": true,
  "data": {
    "id": "string",
    "status": "processed",
    "tags": ["string"],
    "versionName": "string",
    "application": "string",
    "applicationInfo": {
      "id": "string",
      "name": "string",
      "slug": "string",
      "picture": "string"
    },
    "changelog": "string",
    "info": {
      "icon": "string",
      "android": {
        "targetSdkVersion": "string",
        "minSDKVersion": "string",
        "packageName": "string",
        "platformBuildVersionName": "string",
        "platformBuildVersionCode": "string",
        "versionName": "string",
        "versionCode": "string",
        "icon": "string"
      },
      "ios": {
        "plist": {
          "CFBundleDisplayName": "string",
          "CFBundleSupportedPlatforms": ["string"],
          "MinimumOSVersion": "string",
          "CFBundleIdentifier": "string",
          "CFBundleShortVersionString": "string",
          "CFBundleVersion": "string",
          "CFBundleName": "string",
          "CFBundleIcons": ["string"],
          "UIDeviceFamily": ["string"]
        },
        "mobileprovision": {
          "ExpirationDate": "2019-08-24T14:15:22Z",
          "TeamIdentifier": "string",
          "ProvisionsAllDevices": true,
          "TeamName": "string",
          "ProvisionedDevices": "string",
          "signingType": "ad-hoc"
        }
      },
      "pkg": {
        "CFBundleDisplayName": "string",
        "CFBundleIdentifier": "string",
        "CFBundleShortVersionString": "string",
        "CFBundleVersion": "string",
        "CFBundleName": "string"
      }
    },
    "size": 0,
    "processTime": 0,
    "queuedTime": 0,
    "versionCode": "string",
    "error": "string",
    "errorCode": "string",
    "os": "ios",
    "deployer": {
      "name": "string",
      "info": {
        "commitMessage": "string",
        "commit": "string",
        "branch": "string",
        "triggerTimestamp": "string",
        "buildUrl": "string",
        "ciUrl": "string",
        "repositoryUrl": "string",
        "buildNumber": "string",
        "tag": "string"
      }
    },
    "uploadedBy": {
      "id": "string",
      "email": "[email protected]",
      "firstName": "string",
      "lastName": "string",
      "picture": "string"
    },
    "originalExtension": "string",
    "storageProvider": {
      "id": "string",
      "name": "string",
      "region": "string"
    },
    "hasEmmJson": true,
    "updatedAt": "2019-08-24T14:15:22Z",
    "createdAt": "2019-08-24T14:15:22Z"
  }
}

Build not yet processed. This error is returned when the build exists but has not yet completed processing. Retry after a short delay.

{
  "status": false,
  "error": {
    "code": 5014,
    "message": "Build Not Processed"
  }
}

{
  "status": false,
  "error": {
    "code": 3002,
    "message": "Token Expired"
  }
}

{
  "status": false,
  "error": {
    "code": 3001,
    "message": "Entity not found"
  }
}

Key response fields

Field	Description
`status`	Processing status of the build: `pending`, `in_progress`, `processed`, or `error`.
`error`	Human-readable error message, populated only when `status` is `error`.
`errorCode`	Machine-readable error code for programmatic handling. See Build Processing Codes.
`info.android`	Extracted Android metadata: package name, version name, version code, SDK targets, and icon. Only present for Android builds.
`info.ios.plist`	Extracted iOS `Info.plist` metadata: bundle identifier, version, display name, supported platforms, and device families. Only present for iOS builds.
`info.ios.mobileprovision`	iOS provisioning profile details: team, expiration date, signing type, and provisioned devices. Only present for iOS builds.
`info.pkg`	Extracted macOS package metadata. Only present for macOS builds.
`deployer`	CI/CD metadata attached at upload time: branch, commit, build number, and platform URLs.
`size`	Build file size in bytes.
`processTime`	Time taken to process the build, in milliseconds.

Tip

After uploading a build, call this endpoint periodically with the buildId returned from the upload response until status is processed or error. A status of pending or in_progress means processing is still ongoing. If the status is error, check the errorCode field and refer to Build Processing Codes for resolution steps.

Workspace API

Use this endpoint when retrieving build details at the workspace level — for example, in automation that operates across multiple apps using a single credential.

Authentication uses a Service Account token, which is workspace-scoped and not tied to any individual app. The app and build context are both provided via path parameters.

To create a Service Account, see Service Accounts.

Endpoint

GET https://api.applivery.io/v1/organizations/{organizationId}/apps/{applicationId}/builds/{buildId}

Path Parameters

Parameter	Type	Required	Description
`organizationId`	String	Yes	The unique identifier of your Applivery organization.
`applicationId`	String	Yes	The unique identifier of the app the build belongs to.
`buildId`	String	Yes	The unique identifier of the build to retrieve.

Authentication

Authorization: Bearer <your_service_account_token>

Example Request

curl 'https://api.applivery.io/v1/organizations/ORG_ID/apps/APP_ID/builds/552ae3cfcb5abfc58d733b81' \
  -X GET \
  -H 'Authorization: Bearer YOUR_SERVICE_ACCOUNT_TOKEN'

The response schema is identical to the Integrations API.

Key Takeaways

Applivery provides two APIs for retrieving build details: Integrations API and Workspace API.

The Integrations API uses an App API Token for authentication and is scoped to a single app.

The Workspace API uses a Service Account token for authentication and operates at the workspace level.

The response schema is identical for both APIs and includes build status, metadata, and platform-specific information.

Use the buildId to retrieve details and poll the API until the build reaches a terminal state.