How to Fix Zapier Timeout Errors: Complete Troubleshooting Guide
Fix Zapier timeout errors fast: identify the failing step, replay runs, prevent expired data issues, and build resilient automations that don’t time out.
Bullhorn API tokens in Zapier: why refresh fails early
Bullhorn API token refresh issues in Zapier usually mean the wrong restUrl, a stale refresh_token, or mismatched BhRestToken sessions. Use this checklist to fix it.
TABLE OF CONTENTS
If your Bullhorn Zapier integration works for a moment and then starts failing with invalid token, it usually is not “Zapier being flaky.” It is almost always one of these issues:
- You are logging in against the wrong account-specific
restUrl.
- Your
refresh_tokenis being invalidated (often because of credential reuse or another session).
- You are misreading
expires_in(Bullhorn access tokens are short-lived).
This guide walks through the exact Bullhorn token chain (OAuth →
BhRestToken → REST calls), what “expires early” typically means, and a step-by-step diagnostic checklist.Need help debugging Bullhorn + Zapier authentication quickly?
The Bullhorn token chain (why this feels different than normal OAuth)
Bullhorn’s REST API uses a two-layer flow:
- OAuth access token (short-lived)
logincall returns:BhRestToken(session token)restUrl(your account-specific REST base URL)
Zapier steps often look like “OAuth succeeded” and then still fail, because the
BhRestToken + restUrl layer is where most integration issues show up.What expires_in = 600 usually means
Bullhorn access tokens are commonly valid for 10 minutes (600 seconds). In logs you may see
expires_in: 600 and assume it is milliseconds. It is typically seconds, which is consistent with Bullhorn documentation.If you are seeing “expired immediately,” that is usually one of:
- the wrong base URL (
restUrl) for your account
- a token being invalidated by a refresh attempt that succeeded elsewhere
- multiple systems sharing the same credentials and stepping on each other
Issue #1: Wrong restUrl (account-specific REST endpoints)
Bullhorn does not have one universal REST host. The
login response returns a restUrl that includes the correct swimlane for the account.If your code or Zapier app is hardcoding something like
rest42 or rest43, it can work intermittently and then fail in confusing ways. In the transcript, the team discovered the restUrl needed to be corrected for that account before anything else would stabilize.Fix: Always take
restUrl from the login response and use it as the base for subsequent REST calls.Issue #2: Refresh tokens can be invalidated (and they are often one-time-use)
Bullhorn refresh token behavior trips up a lot of automation stacks:
- A refresh token can expire after it is used (Bullhorn returns a new refresh token with each refresh).
- A refresh token can be invalidated for operational reasons.
Bullhorn’s own refresh-token PDF lists common invalidation reasons, including:
- sharing API credentials across multiple applications
- making calls to the wrong data-center URLs
- user/session changes
- network issues where Bullhorn processed the refresh but your client never received the response
Zapier-specific gotcha: if your Zapier integration is refreshing, but not persisting the new refresh token, the next refresh will fail.
Issue #3: Zapier “refreshing immediately” is a symptom, not the root cause
In the transcript, the integration was logging in successfully and receiving token fields, but the session was being invalidated and Zapier tried to refresh right away.
This usually happens when:
- the first REST call returns 401, so the connector immediately attempts a refresh
- the connector has stored a stale refresh token
- multiple environments are trying to refresh the same token chain
Diagnostic checklist (fast)
Work top to bottom. Stop when you find the first mismatch.
1) Confirm you are using the right apps and base URLs
- Bullhorn app: Bullhorn
- Zapier app: Zapier
- Fallback test surface: Make
2) Confirm the OAuth token response looks normal
Capture (screenshot is fine):
access_token
token_type
expires_in
refresh_token(if provided)
If
expires_in is ~600, that is likely expected (10 minutes).3) Confirm login returns a valid BhRestToken + restUrl
- Call:
GET https://rest.bullhornstaffing.com/login?access_token=...
- Confirm response includes:
BhRestTokenrestUrl
Then ensure your later API calls use the
restUrl from this response, not a hardcoded REST host.4) Test a simple REST call and watch the first failure mode
Example:
GET {restUrl}entity/Candidate/{id}?BhRestToken=...
If you get a 401 immediately, confirm you are not mixing:
BhRestTokenfrom one session
restUrlfrom another session
5) Refresh token test (and store the new refresh token)
When the token is expired, refresh via Bullhorn’s OAuth token endpoint using
grant_type=refresh_token.Important behavior:
- On refresh, Bullhorn typically returns a new refresh token.
- Your connector must persist that new refresh token for the next refresh.
6) Rule out “account-specific” issues
The transcript strongly suggests the immediate invalidation was likely account-specific (not a general Bullhorn outage).
If you suspect this:
- Ask Bullhorn support to test the same steps using your credentials.
- Provide timestamps, request IDs if available, and screenshots of the token responses.
Escalation email template to Bullhorn support
Use this to reopen a ticket and get a useful response.
Subject: Bullhorn API refresh token invalidated immediately (Zapier integration)
Hello Bullhorn Support,
We are authenticating successfully via OAuth and receiving
access_token, refresh_token, and expires_in (commonly 600). We then call /login and receive BhRestToken and restUrl. However, the token/session is being invalidated immediately, before the expected expiry window, and refresh attempts fail.Could you please:
- Confirm whether our account is configured to issue refresh tokens and whether any restrictions apply.
- Verify that our credentials are valid and not being invalidated by another session or credential reuse.
- Confirm the correct data-center
restUrlfor our account (and whether it can change).
- Review server logs for our account around these timestamps and advise why the refresh token is invalidated.
Attached:
- screenshots of the OAuth token response
- screenshots/logs of the
/loginresponse
- Zapier request logs showing the first 401 and subsequent refresh attempt
Thank you,
[Name]
[Company]
Fallback: Validate the Bullhorn auth flow outside Zapier using Make.com
If you are unsure whether the problem is Zapier or the Bullhorn account configuration:
- replicate the same OAuth → login → REST call sequence in Make.
- if Make fails the same way, it is likely not a Zapier-only issue.
If you want a second set of eyes, we can diagnose this quickly.
Related Posts
Google Distance Matrix API in Zapier: Setup Guide + Key Restrictions
Set up Google Distance Matrix API in Zapier: create a Google Cloud project, enable billing, generate an API key, and apply safe restrictions so your Zap runs.
