Migrate mission learner data

Transfers mission progress from one user ID to another for email and task evaluation missions.

Prerequisites

Authentication and setup: A valid access token.
Search users: Both the source and the target user must be active and present in the system.

Endpoint

POST /migrate/user_data

Confirm the migration endpoint path for your environment with Mindtickle Support before starting a migration. Do not retry this write against a different path after a 404 Not Found.

Base URL: the API3 host for your region, not the standard API base URL. See Base URLs.

Headers: Authorization: Bearer ACCESS_TOKEN, Content-Type: application/json.

Request

Parameter	Type	Required	Description
`orgId`	string	Required	Organization ID.
`companyId`	string	Required	Company ID.
`oldUserId`	string	Required	Source user ID to migrate data from.
`newUserId`	string	Required	Target user ID to migrate data to.

Request example

{
  "orgId": "1234567890123456101",
  "companyId": "1234567890123456102",
  "oldUserId": "123456789abcd103",
  "newUserId": "123456789abcd104"
}

Response

Field	Type	Description
`workflowId`	string	Identifier of the accepted migration job. Use it to track the migration job status.

Response example

{
  "workflowId": "1234567890123456105"
}

Notes

Data migrated: The job transfers mission completion status, reviewer scores, timestamps, and submission metadata across all module IDs.
Conflict resolution: Modules already completed by the new user are excluded from migration, so existing progress is not overwritten.
Status preservation: An Attempted status carries over if the new user has not yet started the mission. Otherwise, missions that were not started remain Not Started.
Asynchronous processing: The migration endpoint returns immediately with a workflowId and the job runs in the background. The response confirms acceptance of the job only, not completion.
Concurrency: Up to 5 migration jobs run concurrently. The limit exists for system stability.
Rate limits: 5 requests per second, 220 requests per minute, and 3,000 requests per hour.
Retries: If a request times out or its outcome is uncertain, check the returned workflow ID or contact Mindtickle Support before submitting it again.
Scope: Migration includes full mission data for all modules. Partial or field-level migration is not supported.
User accounts: Both oldUserId and newUserId must be active and present in the system. Confirm both accounts are valid and active before you start a migration.
Module scope: The documented request has no module-selection field. Confirm the intended scope before starting a migration; do not assume you can restrict it to individual modules.
Tracking: Capture and securely store the returned workflowId for tracking or support needs.
Testing: Test the API in a staging environment before using it in production.
Errors: Errors are communicated using standard HTTP status codes. See Status codes.
Backdated invitations: When migrating users or recording past progress, invite dates must align with completion dates. The migration workflow supports backdated invitations using an epoch timestamp, so migrated completions are accepted and rewards are calculated correctly. For new users who are not already invited to the module, a backdated invitation is created automatically to match the old user’s original invite timestamp, so historical completion data is processed correctly. If the new user is already invited to the module, the existing invitation timestamp is not modified during migration. Updating existing invitation dates is planned for a future release. For additional context, see Backdated series invitations and Backdated module invitations.

Check status

Use the workflow status endpoint to check progress for the returned workflow ID. Use the standard REST host for your region and Authorization: Bearer ACCESS_TOKEN, with Content-Type: application/json. The migration endpoint itself uses the API3 host. Its status map uses QUEUED, RUNNING, SUCCESS, and FAILED, as documented under Response fields below.

POST /services/data/v2.0/status

Parameter	Type	Required	Description
`processIds`	Array[string]	Required	IDs of the processes. Send each ID as a separate string in the JSON array. The array must contain the `workflowId` value returned by the migration endpoint.

Request example:

{
  "processIds": ["1234567890123456106"]
}

Response fields:

Field	Type	Description
`requestId`	string or null	Request identifier. The response example returns `null`.
`responseCode`	integer	Special response codes from the server.
`responseType`	string	Type of response from the server.
`taskCompleted`	boolean	Completion flag for the status-check request. Read each entry in `status` to determine whether the migration has finished.
`status`	StatusMap	Mapping of process ID to its status: `QUEUED`, `RUNNING`, `SUCCESS`, or `FAILED`.

Response example:

{
  "requestId": null,
  "responseCode": 0,
  "responseType": "STATUS_CHECK_RESPONSE",
  "taskCompleted": true,
  "status": {
    "12345": "SUCCESS"
  }
}