Providers and authentication

Pushing and pulling over HTTPS needs a credential for the remote’s host. Requestly stores one per host and hands it to Git for you. Connect an account once, and clone, push, and pull work without a terminal prompt. Git applies to local projects only, so the Git tab is hidden while a team project is active.

​

Which accounts you can connect

Requestly connects two providers: GitHub on github.com and GitLab on gitlab.com. Each keeps its own credential, and each host holds exactly one credential at a time. Self-managed GitLab and GitHub Enterprise hosts are not offered as connectable accounts. Clone those over SSH instead: Git uses your own system SSH keys, so Requestly stores nothing.

​

Open the Git providers page

Your connected accounts live in App Settings → Git providers, in the same settings group as SSL certificates and Vault. The page is headed “Git providers”, with the line “Manage the git accounts you’ve connected for HTTPS push and pull.”

​

Read the connected accounts list

The page shows a Connected accounts section with the note “Each provider keeps its own credential. Select one to view or manage it.” Each provider sits on its own row with a radio button, its name, and its live status at the right. Select a provider to open its panel below the list. The panel is where you connect, switch method, or remove the credential.

​

Connect an account

Both providers accept two methods: sign in with OAuth, or paste a personal access token. An unconnected provider shows them as two tabs, Personal access token and a sign-in tab named for the provider: Sign in with GitHub OAuth or Sign in with GitLab OAuth.

​

Sign in with OAuth

Signing in avoids creating and pasting a token. Requestly shows you a short code, you approve it on the provider’s website, and the app picks the result up on its own.

​

Connect with a personal access token

Use a token when you prefer to control the scopes yourself, or when sign-in is unavailable for the provider.

​

Token scopes

How each provider is checked differs, and it is worth knowing where a mistake surfaces.

• GitHub. A classic token without the repo scope is rejected as you save it. A fine-grained token does not report its scopes, so Requestly accepts it and a missing permission surfaces later, when a clone or push fails.
• GitLab. Requestly checks for read_api and rejects a token without it. It does not check write_repository at save time, so a read-only token connects successfully and then fails on your first push.

​

Switch how you connect

A host holds one credential, so choosing the other method replaces the one you have. A connected account carries a secondary link under its badge: Use a personal access token instead on a signed-in account, and Sign in with GitHub OAuth instead or Sign in with GitLab OAuth instead on a token account. Clicking it asks you to confirm, in a dialog headed “Switch how you connect to <host>?”.

​

Disconnect or forget an account

The action on a connected panel depends on how you connected. Both ask you to confirm first, and both leave your repositories and commits untouched. They remove only the stored credential, so the next HTTPS push or pull asks you to connect again.

​

Where Requestly keeps your credentials

Your token or sign-in stays on your own machine, inside the desktop app’s encrypted store, protected by your operating system’s keychain. It is never sent to Requestly’s servers and never appears in a project file.

• Requestly reads the credential only while running a Git command against an HTTPS remote, and passes it to that one command. It is never written into the repository’s Git configuration, so a teammate who clones your project never receives it.
• The keychain prompt appears the first time you open the Git providers page, or the first time you run an HTTPS Git command. It does not appear when the app launches.
• When no keychain is available, the account reads Saved for this session only instead of Saved. That credential is lost when you quit, and you connect again on the next start.
• A GitLab sign-in is renewed for you before a Git command runs, so a signed-in GitLab account keeps working without any action from you.

​

Browse your repositories when cloning

Once an account is connected, you can pick a repository from a list instead of pasting its URL. Every provider adds its own tab to the Clone from Git dialog, Browse my GitHub repos and Browse my GitLab repos, described in Connect a project to Git. An unconnected provider shows “Connect GitHub to browse your repos”, or the same line naming GitLab, on that tab, with Sign in with GitHub or Sign in with GitLab and Use a personal access token buttons. Both connect the account without leaving the dialog, and the list loads as soon as they succeed. A connected provider shows:

• A Search repositories box. Typing filters the repositories that account can reach on the provider.
• One row per repository, with a lock icon on private ones, the owner/repo name, when it was last updated, and a Clone button.
• A Load more button under the list when the account has more repositories than the page holds.
• “No repositories found” when nothing matches your search.

Clicking Clone on a row fills the repository’s HTTPS URL into the Paste URL tab. You still choose the destination folder yourself, and then start the clone from there.

​

When Requestly asks you to reconnect

A push, pull, or fetch fails when no credential is saved for the remote’s host, or when the saved one is rejected. The toast that reports it carries an action: Add token when nothing is saved, and Update token when the stored credential was rejected. If the sign-in fails partway, the dialog shows what went wrong and offers both Try again and Use a personal access token instead. The Git overview lists every message you can meet, with what each one means.

​

Next steps