Connections and External APIs

Use this page when an app or HTTP step cannot complete a request, or when the destination may have changed before the run failed. Read the provider’s full message and inspect the destination before retrying a write.

An app asks for authentication again

A 401, 403, or “<account> is no longer authorized” means the connection needs attention. Open the affected step and use Reconnect beside the named account, completing the provider’s sign-in and permission flow.

Automatic retries do not repeat an authentication failure. After reconnecting, test the step and inspect its output. If the failed action writes to the app, check the destination before replacing the run.

401 Unauthorized / 403 Forbidden

Symptom: The step fails immediately with an HTTP 401 or 403 error.

The Cause: The credentials for the third-party app are either expired, invalid, or lack the required permission scopes to perform the requested action.

Retries do not help here. The same request with the same credentials fails the same way every time, so leaving Retry on fail on only delays the failure. Reconnecting the account is the fix.

The Fix: Open the step that uses the account. The App drawer names the broken connection and offers a Reconnect button beside it. Follow the OAuth flow, granting all requested permissions. See Managing Connections.

429 Too Many Requests

Symptom: The step fails with an HTTP 429, in the service’s own words rather than Glow’s. You were sending faster than that service allows.

The Cause: A rate limit at the other end. It is usually temporary, and often self-inflicted: a loop over several hundred items calls the service several hundred times in quick succession.

The Fix:

• Turn on retries and let it pass. A 429 is treated as worth retrying. Open the step’s Test & Debug tab and switch on Retry on fail. Where the service sends a Retry-After header saying how long to wait, Glow waits that long rather than guessing.
• Slow the loop down. Add a Wait step inside the loop body, so the calls are spaced rather than sent together.
• Ask for less. One request that fetches fifty records beats fifty requests that fetch one each.

The step ran for a long time and then failed

Symptom: The step spins for a long time and then fails with a Timeout error.

The Cause: Glow gives an outbound HTTP request 30 seconds by default. If the service is down, slow, or building something large before it answers, the call is cut off.

The Fix:

• Check the service: look at the third-party service’s status page before changing anything on your side.
• Ask for less: if the endpoint supports pagination, fetch smaller pages rather than everything at once. The same applies to an AI step. A shorter prompt carrying less context answers faster.
• Raise the timeout when the service needs longer: the HTTP Request step uses 30 seconds by default and accepts up to 300 seconds.
• For work that outlasts one request: have the remote service accept the job and call you back on a Webhook when it finishes. See System Limits & Quotas.

A timeout does not prove that an external write failed. Check the destination before retrying a step that sends, creates, updates, or charges.

Only part of the destination was updated

Do not start by rerunning the whole workflow. Open the Execution Log, then inspect the writing step’s entries and the destination itself.

A step in Run for each item records work for individual items, so successful items may already have changed the destination even when others failed. Inspect the step’s actual output before referencing summary fields. Build recovery input from the missing source or destination ids and process only those items. If the step says its app action may already have gone through, verify that record in the connected app before repeating it.

For future runs, carry a stable business id through the workflow and use an update or idempotency key where the destination supports one. That gives a repeated request the same identity instead of creating a second record.

What’s Next?

• Reconnect and manage accounts in Managing Connections.
• Inspect the failed request with Debug a Run.
• Design retries and recovery paths with Error Handling & Retries.