504 Gateway Timeout (CloudFront) on /automations/executions/custom with ~1000 executions

I'm using the Zephyr Scale Cloud custom automation format endpoint (POST /automations/executions/custom) to import test execution results in bulk via a zip file containing a JSON results file.

The zip file is small (~4.3KB compressed, ~133KB uncompressed) and contains 1027 test execution records in the standard custom format:

{
  "version": 1,
  "environment": "...",
  "executions": [
    { "result": "Pass", "testCase": { "key": "PROJ-T12345" } },
    ...
  ]
}

Request details:

• Endpoint: POST /automations/executions/custom?projectKey=PROJ&autoCreateTestCases=false
• Body: multipart/form-data with `file` (zip) and `testCycle` (JSON) fields
• Auth: Bearer token, confirmed valid (a deliberately malformed request returns a fast 400 Bad Request, confirming auth/routing work correctly)

The issue:

When submitting the full 1027-execution zip, the request consistently times out at ~60-61 seconds with a 504 Gateway Timeout returned by CloudFront (not by the Zephyr application itself):

HTTP/1.1 504 Gateway Timeout

X-Cache: Error from cloudfront

Via: 1.1 ....cloudfront.net (CloudFront)

I reproduced this twice independently using curl directly against api.zephyrscale.smartbear.com, both times timing out right at the ~60s mark, which matches CloudFront's default origin response timeout. This suggests the backend is taking longer than 60 seconds to process the full batch of executions, and CloudFront is terminating the connection before a response can be returned.

Questions:

1. Is there a documented or recommended maximum number of executions per request for this endpoint?
2. Is there a way to increase the origin timeout for this endpoint, or does it support asynchronous processing (e.g., a 202 Accepted + polling pattern) for larger imports?
3. Is there a better-supported way to bulk-import ~1000 executions into a single test cycle in one request? Or should I accept that I need to split this into multiple requests against the same test cycle to stay under the timeout?

Any guidance on the practical limits of this endpoint would be appreciated.