Appdome Bash Client Library

Bash client library for interacting with https://fusion.appdome.com/ tasks API.

appdome_api.sh contains the whole flow of a task from upload to download.

All APIs are documented in https://apis.appdome.com/docs.

Debugging

Use --verbose / -v to enable debug logging (request URLs, parsed arguments, validation details). Logs are written to stderr with timestamps, matching the Python client format.

When required arguments are missing, the script reports each one with the flag name (e.g. --output (-o) is required) instead of a generic message.

Requirements

• curl

Note: For Linux (Debian based) You can install the requirements with apt-get install curl.

Note: For MAC You can install the requirements with brew install curl.

Basic Flow Usage

Note: Passing overrides for any action is by using json file for example build_overrides.json

Note: For multiple provisioning profiles or/and entitlements - please use ',' as a separator with no spaces. example: --entitlements entt1.plist,entt2.plist

Examples

Android Example:

./appdome_api.sh \
--api_key <api key> \
--fusion_set_id <fusion-set-id> \
--team_id <team-id> \
--app <apk/aab file> \
--sign_on_appdome \
--keystore <keystore file> \
--keystore_pass <keystore password> \
--keystore_alias <key alias> \
--key_pass <key password> \
--output <output apk/aab> \
--build_to_test_vendor <bitbar,saucelabs,browserstack,lambdatest,perfecto,firebase,katalon,kobiton,tricentis_device_cloud,aws_device_farm,app_debug,app_profiler> \
--certificate_output <output certificate pdf> \
--deobfuscation_script_output <file path for downloading deobfuscation zip file> \
--build_overrides <json_file_path> \
--context_overrides <json_file_path> \
--sign_overrides <json_file_path>
--baseline_profile <zip file for build with baseline profile>
--startup_profile <zip file for build with startup profile>
--input_mapping <txt file for build with input obfuscation/minimization mapping>
--cert_pinning_zip <zip file containing dynamic certificates>
--signing_fingerprint_list <path_to_json_file> \

Android SDK Example:

./appdome_api_sdk.sh \
--api_key <api key> \
--fusion_set_id <fusion-set-id> \
--team_id <team-id> \
--app <aar> \
--output <output aar> \
--certificate_output <output certificate pdf> \
--deobfuscation_script_output <file path for downloading deobfuscation zip file> \
--build_overrides <json_file_path> 

iOS Example:

./appdome_api.sh \
--api_key <api key> \
--fusion_set_id <fusion-set-id> \
--team_id <team-id> \
--app <ipa file> \
--sign_on_appdome \
--keystore <p12 file> \
--keystore_pass <p12 password> \
--provisioning_profiles <provisioning profile file>,<another provisioning profile file if needed> \
--entitlements <entitlements file>,<another entitlements file if needed> \
--output <output ipa> \
--certificate_output <output certificate pdf> \
--build_overrides <json_file_path> \
--context_overrides <json_file_path> \
--sign_overrides <json_file_path>
--cert_pinning_zip <zip file containing dynamic certificates>

iOS SDK Example:

./appdome_api_sdk.sh \
--api_key <api key> \
--fusion_set_id <fusion-set-id> \
--team_id <team-id> \
--app <zip file> \
--keystore <p12 file> \  # only needed for sign on Appdome
--keystore_pass <p12 password> \ # only needed for sign on Appdome
--output <output zip> \
--certificate_output <output certificate pdf> \
--deobfuscation_script_output <file path for downloading deobfuscation zip file> \
--build_overrides <json_file_path> 

Signing Fingerprint List (Android only)

The --signing_fingerprint_list option allows you to specify a list of trusted signing fingerprints for Android applications. This is useful when you need to trust multiple signing certificates.

Important Notes:

• This option is only valid for Android applications (APK/AAB files)
• It is mutually exclusive with --google_play_signing, --signing_fingerprint, and --signing_fingerprint_upgrade
• You cannot use --signing_fingerprint_list together with any of the other signing fingerprint options

Usage

--signing_fingerprint_list <path_to_json_file>

JSON File Format: The JSON file should contain an array of fingerprint objects. Each object must include:

• SHA: The SHA-1 or SHA-256 certificate fingerprint (required)
• TrustedStoreSigning: true/false Indicates whether the certificate fingerprint is used for store submissions (e.g., Google Play). (Optional; defaults to false)

Example JSON file (fingerprints.json):

[
  {
    "SHA": "E71186B4D94016F0A3F2A68DF5BC75D27CA307663C6DFDE5923084486D43150E",
    "TrustedStoreSigning": false
  },
  {
    "SHA": "857444B499AAABF7DF388DEA89CC2DA0258273B7C1B091866FA1267E8AA3495D",
    "TrustedStoreSigning": true
  },
  {
    "SHA": "C11E39F29C946A6408E5C5EA65D94FCB05C0DB302B43E6A8ABCB01256257442A",
    "TrustedStoreSigning": true
  }
]

Fields:

• SHA: The SHA-1 or SHA-256 fingerprint of the signing certificate (required)

Update Certificate Pinning

To update certificate pinning, you need to bundle your certificates and mapping file into a ZIP archive and pass it to your build command.

What to include

• Certificate files (one per host), in any of these formats:
  • .cer
  • .crt
  • .pem
  • .der
  • .zip
• JSON mapping file (e.g. pinning.json), with entries like:

  {
    "api.example.com": "api_cert.pem",
    "auth.example.com": "auth_cert.crt"
  }

How to run

Gather all certificate files and pinning.json into a single certs_bundle.zip. Invoke your build with:

your-build-command --cert_pinning_zip=/path/to/certs_bundle.zip

Appdome Test (Standard Launch Tests)

Runs Appdome's Standard Launch Tests on a previously built and signed app. Apps built via the Build-to-Test flow are not eligible — only regular fuse/build (then sign) apps can run Appdome Test.

In the full appdome_api.sh flow, after sign and artifact download:

./appdome_api.sh ... --appdome_test
./appdome_api.sh ... --appdome_test wait
./appdome_api.sh ... --appdome_test atr <appdome_test_results_json>

--appdome_test with no extra args starts the test and prints the task ID. wait polls until complete. atr appdome_test_results_json downloads Appdome Test Results JSON (implies wait). Cannot be combined with --build_to_test_vendor.

Standalone appdome_test.sh uses --task_id as a signed fuse/build ID or an Appdome Test task ID. --wait polls until complete when starting a new test or when --task_id is already running.

If --task_id is already running:

./appdome_test.sh --task_id <task id>
./appdome_test.sh --task_id <task id> --wait
./appdome_test.sh --task_id <task id> --appdome_test_results <appdome_test_results_json>

If --task_id is a completed Appdome Test, download results:

./appdome_test.sh --task_id <appdome test task id> --appdome_test_results <appdome_test_results_json>

If --task_id is a signed build (start a new test):

./appdome_test.sh --task_id <build id value>
./appdome_test.sh --task_id <build id value> --wait
./appdome_test.sh --task_id <build id value> --appdome_test_results <appdome_test_results_json>

Error handling

API failures exit with a non-zero status and print a short, parseable line on stderr:

Appdome API error: HTTP <status> — <api_message>

<api_message> is taken from the response JSON when present (message, or nested Boom output.payload.message, or error + statusCode). The API key is never printed in the default error line; use --verbose for request diagnostics (Authorization is redacted).

Example: create-task rejected before a Build ID exists

Some validation failures (for example an expired Certificate Pinning cert) return HTTP 403 on the fuse/create-task call and never create a Build ID. There is nothing to poll until create-task succeeds.

Typical Boom body from the API:

{
  "statusCode": 403,
  "error": "Forbidden",
  "message": "The certificate file - api.example.com has expired. Please supply an updated certificate to protect your app"
}

What the client prints:

Appdome API error: HTTP 403 — The certificate file - api.example.com has expired. Please supply an updated certificate to protect your app

Consuming errors in CI

Non-zero exit means failure. Match the stderr line to branch on cause:

err_file=$(mktemp)
if ! ./appdome_api.sh ... 2> "$err_file"; then
  if grep -q 'Appdome API error: HTTP 403' "$err_file"; then
    # e.g. refresh pinning certs / update --cert_pinning_zip, then retry
    ...
  fi
  cat "$err_file" >&2
  exit 1
fi

Full API reference: https://apis.appdome.com/docs