Status endpoint

Use the /status endpoint to track app operations and background jobs. Template settings migrations run as background jobs, while some updates, such as additional Android store changes, complete during the API request. Use the returned ticket_token to check the operation’s status and result.

Get ticket status

Retrieve the current status of a background job using the ticket token.

API protocol

Endpoint: https://automate.adjust.com/app-automation/status/{ticket_token}

Method: GET

Response: Ticket Status Response

Parameters

Example

curl --location 'https://automate.adjust.com/app-automation/status/e5b07bb3-b5f3-40a8-8a2d-197d30b6beff' \
--header 'Authorization: Bearer {your-adjust-api-token}'

{
   "status": "completed",
   "kind": "migration",
   "result": {
      "events": {
         "successes": ["purchase", "registration", "level_complete"],
         "failures": []
      },
      "partners": {
         "successes": ["facebook", "google", "applovin"],
         "failures": []
      },
      "trackers": {
         "successes": ["facebook_installs", "google_installs"],
         "failures": []
      }
   }
}

{
   "status": "opened",
   "kind": "migration",
   "result": {
      "events": {
         "successes": ["purchase"],
         "failures": []
      }
   }
}

{
   "status": "failed",
   "kind": "migration",
   "result": {
      "events": {
         "successes": ["purchase"],
         "failures": []
      },
      "partners": {
         "section": "partners",
         "detail": "Could not be started because events section has failed"
      }
   }
}

Status values

Job types

The kind field indicates what type of operation the ticket is tracking:

Understanding results

The result object contains information about what succeeded and what failed during the job. The structure depends on the job type.

Migration results

For migration jobs, the result includes status for each app section that was processed:

{
   "result": {
      "events": {
         "successes": ["event_name_1", "event_name_2"],
         "failures": []
      },
      "partners": {
         "successes": ["facebook", "google"],
         "failures": ["snapchat"]
      },
      "trackers": {
         "successes": [],
         "failures": [],
         "skipped": "Partner facebook not configured in target app"
      }
   }
}

Store update results

For POST /app requests that include stores, the result records the store changes in result.stores. Any background migration adds its section results alongside stores.

For POST /app/{app_token}, store changes are recorded directly in result.successes and result.failures.

For POST /app, changing only stores on an app already managed through the API doesn’t require a migration. First imports, other settings changes, or force_update: true still trigger a migration. If the store IDs are already configured, no store changes are recorded. Empty result fields can be omitted.

Store changes aren’t rolled back if a later background migration fails. Check both the ticket status and the store results.

Partial update results

For partial update jobs, the result shows which items were successfully updated and which failed:

{
   "result": {
      "successes": [{ "app_token": "abc123", "name": "purchase" }],
      "failures": [
         {
            "app_token": "xyz789",
            "name": "invalid_event",
            "detail": "Event not found"
         }
      ]
   }
}

Polling for status

When waiting for a job to complete, we recommend polling the status endpoint with a reasonable interval:

1. Wait 2-3 seconds after receiving the ticket token before the first status check.
2. Poll every 5-10 seconds until the status is completed or failed.
3. Set a maximum timeout (e.g., 5 minutes) to avoid infinite polling.

Data models

Ticket Status Response