Poliogo

Connect Bitbucket

Connect a Bitbucket workspace and pick a repository. Updates arrive as pull requests from Poliogo's own branch.

How it connects
Server-side OAuth
Setup time
Under 60 seconds
Access
Read, plus write for installs

How the connection works

  1. AuthoriseApprove Poliogo on the provider's own screen. No password ever reaches us.
  2. Select repositoryYour repositories are listed for you — nothing to paste or misremember.
  3. Detection stays onScheduled scans re-read your live site and diff it against this scan, so a new tool becomes an update; approving one opens the merge request.

What it looks like once connected

An illustration of this connection inside your Poliogo dashboard — not live data.

Live site checks activeExample
acme/acme-web · main

Detected in this project

  • Stripestripe in package.json
  • SupabaseSUPABASE_URL in .env.example
  • OpenAIfetch to api.openai.com — no SDK
  • PostHognew since your last scan
Last scan: 11 minutes ago3 documents up to date
Files are read in memory and dropped when the request ends. What persists is this list of service names.

Exact permissions requested

Every permission this connection asks for, named as Bitbucket names it on its own consent screen — so you can compare this table to what you are shown.

PermissionGrantWhat it is used for
Repositories: ReadReadList your workspaces and repositories, and read manifests and source text.
Repositories: WriteWritePush the poliogo/compliance-* branch. Required for installs; with Read alone every write answers 403 and the dashboard tells you so.
Pull requests: WriteWriteOpen the pull request carrying the update. Bitbucket takes these from the registered consumer rather than the authorize URL.

Setting it up

What you do, and what you will be looking at while you do it.

  1. Authorise Poliogo on Bitbucket

    Press Connect Bitbucket below and approve on Atlassian's own screen. The token is exchanged server-side.

  2. Know where the permissions come from

    Bitbucket ignores the scope parameter in an authorize URL — the grant is whatever the consumer was registered with. Scanning needs Repositories: Read; installing your policy pages additionally needs Repositories: Write and Pull requests: Write. With Read alone the scan works and the install answers 403, which the dashboard reports rather than silently failing.

  3. Pick a workspace and repository

    Your workspaces and their repositories are listed for you. Choose the repository this product lives in.

  4. Check what it found

    Review the detected services, correct anything, then generate.

  5. Merge the pull request

    The update lands on Poliogo's own poliogo/* branch with a pull request against your default branch. Changes reach your default branch only through a pull request you approve.

Poliogo · New projectExample

Choose how to scan your app

Pick one. We scan your code and settings to find the services your app uses — the scan keeps that list, not your files.

Git RepositoryRecommendedThe most accurate scan — we read the dependencies your app actually ships.Choose another way
GitHubGitLabBitbucket

Connect Bitbucket and pick a repository — read-only, and we never write.

Authorise on Bitbucket

Repositories: ReadRead
Repositories: WriteWrite
Pull requests: WriteWrite

Granted on Bitbucket's own screen — this panel can show it, never widen it.

Connect Bitbucket

Select repositories

Find a repository (12)
acme-webPrivateacme-siteacme-docsAlready scanned
Choose which repositories Poliogo can read →Read my project
Tell us what you use instead
The Poliogo setup screen for Bitbucket, drawn from the same catalogue the app reads. An illustration — not live data, and nothing here is clickable.

What Poliogo detects from Bitbucket

The right-hand column is the part worth reading: it is what this connection cannot reach even if we wanted it to.

What it reads

  • Dependency manifests — package.json, requirements.txt, Cargo.toml, go.mod, composer.json, pubspec.yaml and the rest.
  • The endpoints your code actually calls. A raw fetch to api.openai.com is found even with no SDK installed.
  • Environment variable names in .env.example — STRIPE_SECRET_KEY proves Stripe without reading any secret.
  • Your framework and where its routes live, so generated policy pages land in the right folder.
  • Cookies and tracking scripts referenced anywhere in the source.

What it never reads

  • Repositories you did not select.
  • The value of any secret or environment variable.
  • Your default branch, except through a pull request you approve — updates arrive on a poliogo/* branch.

Ready to connect Bitbucket?

The free plan covers one project with no credit card. You approve everything before a single document is written.

Poliogo is a compliance management platform, not a law firm. What it produces is not legal advice. See exactly what each connection reads.