Status polling pattern
The typical polling flow looks like this:Getting submission status
UseGET /api/integrations/submissions/{submission_id} — there is no /status suffix.
errorMessage, errorType, isRetryable, retryCount — not a nested error object. The terminal submission statuses are complete and failed.
Polling strategy
Basic polling loop
Exponential backoff
For long-running submissions, start with short intervals and back off over time:Retrieving results
Once an asset is done, fetch its result withGET /api/integrations/submissions/{submission_id}/assets/{asset_id}. The result includes the asset’s status, issueCount, and an issues array. For the flat enriched issue list call .../assets/{asset_id}/issues; for AI-clustered topics call .../assets/{asset_id}/topics.
severity is one of CRITICAL | MAJOR | MINOR | INFO, and issue status is one of OPEN | ACKNOWLEDGED | AWAITING_HUMAN_INPUT | RESOLVED | DISMISSED.
The clustered topics endpoint returns { "assetId", "topics", "orphanIssues", "metadata" }. Topics group two or more related issues; orphanIssues are unclustered singletons and are normal. The issues and topics endpoints return 404 if the asset has not finished processing yet.
Complete polling example
A full end-to-end example:Polling recommendations
Polling vs webhooks
| Factor | Polling | Webhooks |
|---|---|---|
| Latency | Delayed by poll interval | Real-time |
| Complexity | Simpler to implement | Requires an endpoint |
| Throughput | Better for few submissions | Better for many |
| Load | Higher on the API | Lower on the API |
Handling timeouts
If a submission does not finish within your timeout:- Re-fetch the submission later — it may simply still be processing.
- Check the per-asset
errorMessage,errorType, andisRetryablefields. - Retry a failed, retryable asset with
POST .../assets/{asset_id}/retry. - Switch to webhooks for more reliable completion detection.