Hi,
We have a custom Flow action that sometimes cannot finish inside Flow’s 10-second response window. We followed the action endpoint contract in Create Flow action endpoints, and the same pattern was discussed in Retry-After is ignored in flow action response. The action is running normally, but the workflow run UI presents it as a failure:
and in run details:
On our side all is implemented according to the documentation, but because of how UI communicates the in-progress workflow action, merchants are sometimes frustrated and attempt to retry the workflow from the Flow manually.
What we return for one action_run_id:
- The first POST returns 202 with an empty body, in well under a second. The work is accepted and continues asynchronously. We do not return 200 until the action has actually been fully finished.
- Later POSTs for the same
action_run_id, while the work is still in progress, return 429 withRetry-After(seconds, between 5 and 3600) and a short body that tells that this action is still in progress. - When the work is finished we return 200 with an empty body, or 400 with a merchant-facing message if it permanently failed (e.g. provided payload is incorrect or action was a duplicate, etc).
That matches the documented meanings:
- 202: accepted, not yet processed. Flow resends the POST at increasing intervals for up to 36 hours.
- 429 with
Retry-After: minimum wait of 5–3600 seconds, plus jitter, with longer waits after repeated 429s. - 200: processed.
- Any other 4xx: failed, and the merchant should see that response.
What the merchant sees
While step 2 is still returning 429, the run shows:
- “This step has errors”
- “This action failed and we’re retrying it. Check step configuration.”
Nothing is misconfigured, and the action has not failed. Flow is correctly retrying an in-progress action. The copy tells the merchant the opposite.
We also tried answering every poll with 202. The endpoint still answered in a few hundred milliseconds, but Flow then recorded:
Ran into transient error: Waited over 10 seconds for non-202 response
with the step status Retrying. From the logs, that 10 seconds is Flow waiting after a fast 202 for a non-202 status. It is not our server taking 10 seconds to respond. Returning 429 on the later polls is what produces that non-202 status, which is why we do it. Flow then displays the 429 as an error anyway.
Shop we used for testing: rate-limit-test.myshopify.com
Sample action_run_id: bf869cdc49a0b2e381826690d54e84e9302d8f08
Time shown in Flow: Oct 14, 2026 at 8:56 PM (store timezone)
We double checked logs to ensure that the endpoint is answering inside the 10-second limit.
Our request / suggestion:
Please treat 202, and 429 with Retry-After, as “still running” until the run ends with 200 or a non-retryable 4xx, or until the 36-hour retry window is exhausted.
While those retries are in progress the status may be something like: “This action is still running.”. From our point of view, when Flow UI says that the action failed, or to check the step configuration, this provides negative UX for both merchant and us. A real failure should stay reserved for a non-429 4xx, or for retries that stop after 36 hours.
Happy to provide a workflow run link or more logs.