Let processing happen.
Uploading and decoding are separate steps. Your app can keep working while MovePacket processes the file, then retrieve the result when it is ready.
The activity lifecycle#
| Status | Meaning | Your next step |
|---|---|---|
received |
The original and activity record have been stored | Save the ID; keep polling |
queued |
Processing has been dispatched or is awaiting recovery | Keep polling |
ready |
Decoded JSON is available | Retrieve data; stop polling |
failed |
Processing ended with an error | Read error_code; stop polling |
processing is a list filter and dashboard grouping, not a stored activity status. It includes received and queued. Fast processing can mean you never observe the earlier states.
Poll with a limit#
Start with a status request every two seconds. Stop on ready or failed, and set a maximum wait for your application. If that wait expires, keep the activity ID and resume checking later. Do not turn a client timeout into a new upload automatically.
The runnable quickstart demonstrates bounded polling, request timeouts, and safe handling of terminal failures. There is no processing-time guarantee in the private beta.
Retry safely#
For connection failures or HTTP 429, 502, 503, and 504, use a limited number of retries with increasing delays and jitter in production. Respect Retry-After when supplied. Do not blindly retry authentication, validation, or file-size errors.
If an upload response is lost, retry the same bytes with the same workspace key. Content deduplication returns the existing activity ID. Re-uploading a terminal failed activity does not restart decoding; correct the source file or inspect its failure first.
MovePacket's queue handler tolerates duplicate delivery. A periodic recovery pass checks stranded work, and repeated processing failures eventually become a visible failed status. Your integration should treat the activity endpoint as the current source of truth.
Webhooks are planned#
Outbound webhooks, signing secrets, delivery retries, and delivery history are not available yet. There is no webhook registration endpoint. Use polling against the implemented status endpoint today.
The intended webhook behavior is to let your server react when an activity is ready or has failed. Event names and payloads will be documented when that contract is implemented and tested. Avoid building against speculative event examples.