Connections and External APIs
Resolve app authentication errors, HTTP failures, timeouts, and partial writes without creating duplicate records. Check the destination before retrying. For an unavailable action, follow Replacing an Unavailable Action.
- Use it to
- Diagnose 401/403 authentication errors, 429 rate limits, HTTP timeouts, and partial or duplicate external writes
- Find it
- Step App drawer → Reconnect, Connections → Connections, or Step App drawer → Test & Debug
- Limits
- 30 s default outbound HTTP timeout (300 s max) · 0 to 10 retries with 0 to 60 s base delay
- Instead
- Data and Mapping Problems (when the external call succeeded but sent literal braces or wrong field values)
Always check the destination before retrying a write. A failed Step or timeout does not prove the action failed at the remote service. If the execution is still running, inspect that run rather than starting another.
| Symptom or HTTP status | Automatic retry? | Typical cause | Primary fix |
|---|---|---|---|
| Account no longer authorized | Skipped when connection is classified unavailable | Expired OAuth token or revoked app grant | Owner clicks Reconnect in the App drawer, then runs a safe real action test |
401 Unauthorized / 403 Forbidden | Not retried when credentials/permissions fail | Invalid API key, expired token, or missing resource scope (403) | Check resource permissions in the provider or reconnect in Managing Connections |
429 Too Many Requests | Retried if Retry on fail is on (honors Retry-After) | Burst loop traffic or exhausted daily/account quota | Enable Retry on fail, add a Wait inside a Repeater loop, or batch requests |
Timeout | Skipped on interrupted external calls | Request exceeded 30s default HTTP timeout (300s max) | Verify destination first, fetch smaller pages, raise timeout, or use an async Webhook |
An app asks for authentication again
If Glow reports that an account is no longer authorized, open the affected Step and use Reconnect when offered. If the account belongs to someone else, ask its owner to reconnect it. A failed execution can also offer Reconnect to the owner of the account used in that historical run. Reconnecting repairs the account, but does not automatically retry the failed run. Verify access with a safe real action test rather than saved-data replay (see Testing & Debugging).
401 Unauthorized / 403 Forbidden
The service rejected authentication (401) or permission to access the target resource (403). Retrying the same request will not fix it. Reconnecting alone will not resolve a 403 if the account lacks permission for that resource. Read the provider’s error message, grant the required scope or check the Authorization header, and see Managing Connections.
429 Too Many Requests
A request-rate limit or usage quota was reached. This often happens when a loop sends bursts of requests or shares a quota with other automations:
- Retry safe requests: Confirm whether any write already changed the destination, then enable Retry on fail in Test & Debug. A recognized
Retry-Afterheader adjusts the delay; see Error Handling & Retries. - Space out or batch requests: For a multi-Step Repeater, add a Wait inside the loop body before the return wire. Run for each item is a single-Step batch without a multi-Step body. Where supported, fetch or update records in a single batch call instead of one request per item.
The step ran for a long time and then failed
The request did not finish within its timeout, and the remote service may still finish processing after Glow stops waiting:
- Check the destination and service status: Confirm whether the write completed in the connected app, and check the provider’s status page.
- Fetch smaller pages or raise the timeout: Request smaller pages or shorter AI prompts. The HTTP Request Step defaults to 30 seconds and accepts up to 300 seconds.
- Use a webhook callback for long jobs: Have the remote service accept the job and call back a Webhook when finished. See System Limits & Quotas.
Duplicate rows or emails
Compare the destination records with the writing Step’s execution history before running anything again.
Check what already happened
Open the destination spreadsheet, mailbox, or app. Compare record IDs, recipients, timestamps, and any business ID carried by the automation.
Match the writes to runs
Use the Execution Log and the Step’s Executions tab to compare execution IDs, timestamps, retry attempts, and any real isolated action tests.
Recover only the missing work
In Run for each item, successful items may already have updated the destination even when other items failed. Inspect the Step’s output and the connected app, build recovery input containing only the missing IDs, and review every downstream write before running it. Moving the canvas run point to a writing Step still executes its downstream path.
For future writes, use a stable business ID and an update or provider-supported idempotency key where available. A retry setting alone does not prevent duplicates.
- Run
- Verify the destination app state, then run a single safe action test on the repaired Step.
- You should see
- The Step completes without a 401, 403, 429, or timeout error, and no duplicate write occurs.
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.