Setting up API Token with SourceTree

[HenryRawas]

I followed the instructions on this page

https://support.atlassian.com/bitbucket-cloud/docs/add-an-api-token-to-sourcetree-or-another-application/

I am running SourceTree version 3.4.31 on Windows.

One discrepancy is that at the point of pasting the Token. Rather than a field, I see a button "Refresh API Token" When I click that I have to paste the token into the password field.

After I do that, I see a "Authentication OK" status.

However when I then try to push some changes, it fails with a message that use of passwords is deprecated.

If I wait for a while, things work, but then days later it fails again.

[Tomislav Tobijas]

Hi @HenryRawas ,

There seems to be an issue with what you're experiencing. People have discussed it here https://community.atlassian.com/forums/Sourcetree-questions/app-password-warnings-after-updating-Bitbucket-account-in/qaq-p/3252148 but I'm not sure if there's any 'smart solution' 🫤

I know people are still trying to find a decent solution, but I guess we'll see... 👀

Cheers,
Tobi

[Gabriela]

The intermittent part is the giveaway. Bitbucket Cloud app passwords are in their deprecation brownout right now — Atlassian shuts them off in escalating windows through 27 July, then kills them entirely on 28 July 2026. Your push works between windows and fails inside them, and the deprecation warning confirms SourceTree is still sending an app password, not the API token.

So the token isn't in play yet. On 3.4.31 the version is fine, API Token auth landed back in the 3.4.x line, so the account is just still wired to the old credential. Viswanathan's first step is the one that matters here — clear the bitbucket.org entries from Windows Credential Manager (Control Panel > Credential Manager > Windows Credentials) so the stale app password stops being resent.

Then re-add the Bitbucket account in SourceTree and set the Auth Type to API Token. Pasting the token into the password field of a Basic account is what kept you on the old path. Generate the token at id.atlassian.com with the read:repository:bitbucket and write:repository:bitbucket scopes. Once the account is on the token path and the old credential is gone, the brownout windows stop affecting you.

If SourceTree still shows Refresh API Token instead of a token field, remove the account entirely and add it fresh — editing an existing app-password account tends to keep the old auth type.

[HenryRawas]

Thanks for the detailed steps.

I cleared out the bitbucket entries from Windows Credential Manager.

I went into SourceTree Options / Authentication and removed all the entries - Accounts, Saved passwords, etc.

From there I chose to Add Account.

In the Credentials popup I select API Token, but I still see the "Refresh API Token" button.

Based on other posts I then closed SourceTree, went into the Atlassian files and deleted the passwords file and user hosts file.

I then uninstalled SourceTree, and then did a new install.

When I went to add the account again, I select API Token, but I still see the Refresh button. So something is still not right.

One difference now, is if I do a pull, I get a pop-up "Login required for: bitbucket.org" asking for username and password

This should not be that hard. Why can't SourceTree have a button to clear out all the old stuff it is caching?

Any ideas what else to try?

[Viswanathan Ramachandran]

hi @HenryRawas 

Could you confirm:

• Are you using Embedded Git or System Git in SourceTree? (Tools - Options - Git)
• Is this happening with all Bitbucket repositories or only one?
• Does the problem occur only after restarting SourceTree, or it happens while SourceTree remains open?

Also, if could run these and share the details (please mask if required)

git --version
git remote -v
git config --show-origin --get-all credential.helper
git config --list --show-origin | findstr credential

My suspicion

It’s more likely one of these:

1. Multiple Git credential helpers configured.
2. A bug in SourceTree 3.4.31’s Bitbucket authentication.
3. Git Credential Manager and SourceTree both trying to manage credentials.
4. A repository or global Git configuration overriding authentication.

[HenryRawas]

[HenryRawas]

All repositories

All the time.

It is so long since I used git command line, I don't know how to do it anymore.

[HenryRawas]

I uninstalled SourceTree again.

I cleaned up the credential manager again.

This time I deleted the entire SourceTree folder under AppData/Local/Atlassian

Installed SourceTree again.

Re-added the repositories.

I still see the Refresh API Token button, but I am able to do a Push

Is there a way to tell if it is actually using the Token?

[Harper_ Peter]

@HenryRawas HenryRawas - no - I am in exactly the same position as you. Hey Atlassian - just turn it off. How much time have you wasted on this Henry? I'm thinking of sending Atlassian an invoice!

[Viswanathan Ramachandran]

I'm sorry @HenryRawas  I understand how tiring and frustrating it is. If you're on supported plan, I recommend you to reach out to https://support.atlassian.com 

[Gabriela]

The clean way to know is the date itself. App passwords get switched off entirely on 28 July, so if your pushes still work past that, it's the token. Nothing else survives that cutoff. Right now you're mid-brownout, so a push working today isn't proof.

To check before then, open Windows Credential Manager and find the bitbucket.org entry SourceTree uses. Look at the username on it. An API token authenticates as your Atlassian email; an app password uses your Bitbucket username. You wiped the whole AppData folder and re-added with API Token, so odds are it's on the token now.

[Harper_ Peter]

You keep mentioning API tokens but in a previous discussion on this forum a member of Atlassian staff said that OAuth would also work with SourceTree. Is that the case?

[Gabriela]

Yeah, OAuth still works with SourceTree, and it's not on the chopping block like app passwords are. Might actually be your easiest way out of this whole mess.

Drop the Bitbucket account you've been fighting (Tools > Options > Authentication), then Add Account again and pick OAuth for the auth type (not Basic or API Token). A browser pops up to authorize. After that SourceTree holds the OAuth token itself, so there's no app password, no API token, no Credential Manager juggling, and no more Refresh API Token button.

[HenryRawas]

Good to know about the OAuth option.

To follow up on the previous post, the credential manager seems to have both. I cleared out all the git and sourcetree entries before the last install, but after trying to use the API Token in SourceTree it created a bunch of new entries.

git:https://bitbucket.org - this has username

git:https://myemail@bitbucket.org - this has my email

git:https://myusername@bitbucket.org - this has my username

hg:https://bitbucket.org - this has email

hg:https://myemail@bitbucket.org - this has my email

hg:https://myusername@bitbucket.org - this has my username

sourcetree-rest:https://bitbucket.org - this has email

sourcetree-rest:https://myemail@bitbucket.org - this has my email

sourcetree-rest:https://myusername@bitbucket.org - this has my username

Which of these does source tree use?

Why does it create versions with email and versions with username?

This looks like a bug in source tree Authentication config.

[Gabriela]

For git push/pull, only the git:https://... entries matter. The hg: ones are Mercurial, ignore those, and the sourcetree-rest: ones are SourceTree's own account API rather than your git auth.

Of the three git: entries, the one git falls back to is git:https://bitbucket.org, the host-only one with no user in it. Your remotes are plain https://bitbucket.org/..., so git looks up by host and lands on that entry. And that's the one holding your username, which is app-password style. So even with a token sitting in another entry, git keeps sending the username credential and Bitbucket reads it as an app password. That's your CHANGE-3222.

The email-vs-username split isn't really a bug. An API token authenticates as your email, an app password as your Bitbucket username, so the switch left both flavours side by side. Messy, but not SourceTree breaking.

So to clean it up, delete all three git:https://...bitbucket.org entries, then do a fetch. When it prompts, put your Atlassian email as the username and the API token as the password. It rebuilds one clean email entry and uses that. Or the OAuth route skips all of this, since SourceTree then holds the token itself instead of scattering these entries.

[HenryRawas]

I followed your instructions.

I deleted all the git: entries.

I even rebooted Windows to make sure there was nothing cached in memory.

I started SourceTree and did a fetch.

It prompted for user and password. I chose the user / token option (rather than browser)

I entered my email and put the token as password.

The user and password pop up came up again. I entered the email and token again. It still wouldn't accept it. Repeated 3 times.

I finally gave up and went to Options / Authenticator, and selected OAuth.

Hopefully this will work.

[Gabriela]

Ah, that one's on me. I gave you the REST-API username by mistake. Your email is what you'd use for REST calls, but for a git push or fetch the username isn't your email at all. It's x-bitbucket-api-token-auth (or your exact Bitbucket username), with the token as the password. That's why it kept bouncing you: git was sending email:token, and Bitbucket won't take the email there.

So in that prompt, try x-bitbucket-api-token-auth as the user and the token as the password.

Honestly though, SourceTree's handling of API tokens is genuinely shaky. There's an open bug on it (SRCTREE-8218) because SourceTree only gives you a username/password box while the token flow wants the email for REST and the x- username for git, and it gets confused between the two. That's the whole reason I'd point you at OAuth. It skips this username puzzle completely, since you authorize in the browser and SourceTree holds the token itself.

[Viswanathan Ramachandran]

hi @HenryRawas 

• check for any cached credentials - windows credentials manager - remove them
• Verify the repository remote URL and confirm the remote is the expected HTTPS Bitbucket Cloud URL and hasn’t been configured with an old username/password or another credential source.
• Check if Git credential manager is using old password - remove
• delete and try recreating the account with the new API token

If it helps see similar thread - https://community.atlassian.com/forums/Sourcetree-questions/app-password-warnings-after-updating-Bitbucket-account-in/qaq-p/3252148

Let me know, if you have found a solution, spread the word :)