Get migration issues
The per-item issue log in four lists: items that failed, items intentionally skipped with the reason why, non-blocking warnings (things the engine worked around without failing the run), and items the self-healing layer healed — failures that were automatically resolved during or after the run, reported separately so a fixed item is never listed as failed.
Use this to answer “which products didn’t make it, and why?”. The log is embedded into the durable snapshot before a run’s working files are reclaimed, so it stays readable for finished runs. Entries are sanitised — entity, name, status, and reason only; never request bodies or credentials.
API-token callers: while a run is still live, this endpoint reads from the engine, which is not available with bearer authentication (403 not_available) — the issue log becomes readable once the run reaches a terminal status.
Authorizations
A bearer token from Login, sent as Authorization: Bearer <token>. Valid for 10 days by default; scoped to the user and organisation it was issued for. Rotating or disabling the organisation's API credential immediately invalidates all outstanding tokens. Browser calls from a signed-in app.vortexiq.ai page are also accepted via session cookie — see Authentication.
Path Parameters
The migration request id returned by Create migration.
Response
Failures, skipped items, and warnings.
Skipped items pass through the engine's shape verbatim — expect at least entity and reason; other keys vary by entity type.
Non-blocking issues (for example an unrecoverable 404 source image, or a dropped filter context). They do not fail the run.
Failures the self-healing layer resolved automatically. Folded out of failures so a fixed item is never reported as failed.