Architect Flow Timeout During Multi-Org OAuth Token Refresh

Architect & Flows
1

Why does the /api/v2/platform/oauth/token endpoint occasionally returns a 504 when triggered from an Architect flow using the Web API action?

We are handling multi-org OAuth refreshes for AppFoundry partners. The flow hangs at the HTTP request step before timing out.

{"error": "Gateway Timeout"}

The issue correlates with high concurrency during PST business hours. Are there specific rate limits on platform API calls initiated from Architect?

2

Check your concurrent token request volume. The 504 indicates the gateway is overwhelmed by simultaneous OAuth refreshes from the flow.

Cause:
Platform API rate limits are exceeded during peak PST hours, causing queue saturation.

Solution:
Implement exponential backoff in the Web API action or stagger requests. Limit concurrency to 10 TPS per org to stay within WebSocket connection caps.

3

To fix this easily, this is to implement a retry mechanism with exponential backoff directly within the Architect flow, rather than relying on the Web API action’s default behavior which often fails silently or hangs. When dealing with multi-org OAuth refreshes, the platform API gateway can indeed saturate during peak PST hours, causing those 504 Gateway Timeout errors.

Here is how to structure the retry logic:

  • Add a Data Action before the Web API call to set a retry_count variable to 0.
  • Configure the Web API action to capture the response status code into a variable, e.g., api_status.
  • Use a Decision node to check if api_status equals 504 or 429.
  • If true, increment retry_count and wait for a duration calculated as 2 ^ retry_count seconds (1s, 2s, 4s, etc.).
  • Loop back to the Web API action.
  • If retry_count exceeds 3, trigger an error path for manual review.

This approach prevents the flow from hanging indefinitely and reduces load on the gateway. Also, ensure you are not exceeding the recommended 10 TPS per org. While the suggestion above mentions staggering requests, adding explicit backoff in the flow architecture provides more control over the retry sequence. This is particularly important for legal discovery workflows where chain of custody requires consistent audit trails for every API interaction. If the token refresh fails repeatedly, log the specific error payload to a secure S3 bucket using the Recording API bulk export configuration, ensuring metadata includes the timestamp and org ID for later forensic analysis. This ensures that even if the OAuth token fails, the attempt is recorded for compliance purposes.