Bullhorn API tokens in Zapier: why refresh fails early
🛠️

Bullhorn API tokens in Zapier: why refresh fails early

View Details
Link
Apps
Bullhorn
Bullhorn
Zapier
Zapier
Make
Make
Hubs
Productivity
Productivity
Unsplash Cover
Unsplash Cover
Video
Prompt status
Draft ready
Short video prompt
Create a 9:16 vertical video for TikTok/IG Reels (20–35s) based on this blog post:

Title: Bullhorn API tokens in Zapier: why refresh fails early
URL: https://connex.digital/blog/bullhorn-api-tokens-in-zapier-why-refresh-fails-early

Audience: Zapier builders, ops teams, and developers troubleshooting Bullhorn + Zapier auth.

Goal: Explain why Bullhorn token refresh fails “early” and give a fast diagnostic checklist. Make it feel practical and calming, not blamey.

Branding:
- Include “Connex Digital” in on-screen text at least twice.
- Include Connex Digital logo subtly in-frame throughout.
- High-contrast on-screen text and burned-in captions.

Tone + voice:
- Warm US confident, energetic and clear.
- VO should sound like a helpful expert who has seen this bug a lot.

Music:
- Upbeat, modern creator tutorial background beat, low volume under VO.

Pacing + editing:
- Fast cuts.
- Pattern interrupts every 2–3 seconds (quick zooms, b-roll swaps, text callouts).

Structure:
1) Hook (first 2 seconds): call out the pain (“Invalid token after it worked 1 minute?”)
2) 3–5 quick points (very short):
- Bullhorn has 2 layers: OAuth token + BhRestToken/restUrl session.
- Most failures are wrong account-specific restUrl from /login.
- expires_in=600 is usually seconds (10 minutes), not ms.
- Refresh tokens often rotate. If you do not store the new refresh token, the next refresh fails.
- If first REST call gets 401, Zapier refreshes immediately. That is a symptom.
3) CTA (last 4–6 seconds): invite to book a short call.

On-screen text suggestions (keep concise):
- “Bullhorn + Zapier ‘Invalid token’?”
- “It’s usually NOT Zapier.”
- “Check your restUrl (from /login)”
- “expires_in=600 = 10 min”
- “Store the NEW refresh_token”
- “Connex Digital Fix Checklist”

Visual suggestions:
- B-roll of Zapier editor, API logs, terminal snippets.
- Simple motion graphics showing: OAuth → /login → BhRestToken + restUrl → REST call.

End card:
- Big CTA button + URL: http://connex.digital/book/short
- Add small text: “Connex Digital”

Assumptions:
- The public post URL above is correct.
- Viewer is using Zapier’s OAuth flow or a custom Zapier integration that stores tokens.
Long video prompt
Create a 16:9 YouTube video (6–10 minutes) based on this blog post:

Title: Bullhorn API tokens in Zapier: why refresh fails early
URL: https://connex.digital/blog/bullhorn-api-tokens-in-zapier-why-refresh-fails-early

Target viewer:
- Zapier power users, RevOps, and developers integrating Bullhorn’s API.

Video theme: Newsroom explainer (clear, structured, “here’s what’s actually happening”).

Presenter:
- Use an avatar talking head.
- Presenter name: Paul (founder).
- Voice: conversational expert, warm US confident.

Music:
- Upbeat, trendy, subtle under VO.

Core promise:
- “If Bullhorn works for a moment then fails with invalid token, here’s the real cause and the fastest checklist to fix it.”

Required branding:
- Use Connex Digital logo subtly in the corner during most of the video.
- Mention “Connex Digital” verbally in intro and recap.

Visual style:
- Mix of avatar A-roll, b-roll of Zapier editor, API logs, and simple motion graphics.
- Use on-screen headings and key takeaways.

Outline (match the article sections and keep the same terminology):

1) Hook (0:00–0:20)
- Start with the common symptom: “OAuth succeeds… then ‘invalid token’.”
- Tease the key insight: Bullhorn has a two-layer flow and most issues live in the BhRestToken/restUrl layer.

2) Intro (0:20–0:45)
- Who this is for.
- What we will cover.
- Mention the post URL on-screen.

3) The Bullhorn token chain (0:45–2:30)
- Explain visually: OAuth access token → /login → BhRestToken + account-specific restUrl → REST calls.
- Clarify why Zapier can look ‘fine’ and still fail.
- On-screen graphic: flow diagram with arrows.

4) What expires_in=600 usually means (2:30–3:15)
- Explain: 600 seconds = 10 minutes.
- Call out the common misconception (milliseconds).
- Quick check: what ‘expired immediately’ typically indicates.

5) Issue #1: Wrong restUrl (3:15–5:00)
- Emphasize: restUrl is account-specific, must be taken from /login.
- Show a short example of the correct pattern: read restUrl, then base all endpoints on it.
- Visual: highlight restUrl in a sample JSON response.

6) Issue #2: Refresh token rotation + invalidation (5:00–7:00)
- Explain that refresh tokens often rotate.
- Spell out the Zapier-specific gotcha: refresh succeeds but new refresh token is not persisted.
- Mention common invalidation reasons: shared credentials across apps, wrong URLs, user/session changes, network issues.

7) Issue #3: “Refreshing immediately” is a symptom (7:00–8:00)
- Explain the chain reaction: first REST call 401 → connector refreshes right away → looks like token expired instantly.
- Give the practical debugging mindset: find the first mismatch.

8) Diagnostic checklist (8:00–9:20)
- Present the checklist as 6 steps:
1. Confirm correct apps + base URLs.
2. Inspect OAuth response fields.
3. Confirm /login returns BhRestToken + restUrl.
4. Test a simple REST call using that restUrl.
5. Refresh test and store NEW refresh token.
6. Rule out account-specific issues (and what to send support).
- Show each step with big on-screen text.

9) Recap + CTA (9:20–end)
- Recap the 3 main causes.
- Invite viewers to book help.
- CTA URL on-screen: http://connex.digital/book/video

On-screen text (examples):
- “Bullhorn has 2 layers”
- “OAuth ≠ REST session”
- “restUrl is account-specific”
- “expires_in=600 = 10 min”
- “Refresh tokens rotate. Store the NEW one.”
- “Connex Digital: Fix Checklist”

Assumptions:
- The public post URL above is correct.
- The viewer has access to logs that show the first REST 401 and the refresh attempt.
General
🔑 Keyword Goals
Generate LK
Generate NL
LinkedIn Post Content
🚀 Struggling with Bullhorn API tokens in Zapier? You're not alone! Our latest blog post dives into common issues like invalid tokens and how to troubleshoot them effectively.

🔑 Key takeaways:
- Understand the Bullhorn token chain and why issues may arise.
- Learn about refresh token behavior and the importance of the correct restUrl.
- Follow our diagnostic checklist to quickly get back on track.

Don't let token troubles slow you down! Read more here: Bullhorn API tokens in Zapier: why refresh fails early

#Bullhorn #Zapier #APIIntegration #ConnexDigital #RevOps
Hidden
Tags db
🏷️
OAuth
Full URL
Unsplash Cover
Unsplash Cover
Prompt last generated
Mar 22, 2026
KW AI GEN
Bullhorn API, Zapier integration, token refresh issues
Last edited time
Jul 27, 2026 05:34 PM GMT+0
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_token is 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?
Book a free consultation

The Bullhorn token chain (why this feels different than normal OAuth)

Bullhorn’s REST API uses a two-layer flow:
  1. OAuth access token (short-lived)
  2. login call 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

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:
    • BhRestToken
    • restUrl
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:
  • BhRestToken from one session
  • restUrl from 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:
  1. Confirm whether our account is configured to issue refresh tokens and whether any restrictions apply.
  2. Verify that our credentials are valid and not being invalidated by another session or credential reuse.
  3. Confirm the correct data-center restUrl for our account (and whether it can change).
  4. 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 /login response
  • 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.
Book a free consultation