Skip to main content
The Git category gives you a common view of a user’s code hosting account: their repositories, and each repository’s pull requests, issues, tags, releases, branches and commits. Use it to: import a customer’s repositories, show recent pull requests in a dashboard, link commits to deploys, or read release notes, whichever Git host they use.

Endpoints

Parameters and full schemas: Unified API reference. Which Git providers support which endpoints: bundleup.io/integrations.

Identifying a repository

{repo} is the repository’s full_name from GET /v1/git/repos (for example octocat/hello-world), URL-encoded because it contains a slash:
With the SDKs, pass full_name as shown in their reference. Always take full_name from the repos endpoint rather than building it, since its format follows the provider (GitLab namespaces can be nested, for example).

Example: recent pull requests across all repositories

Each call is one request toward the connection’s rate limit of 100 per minute. For many repositories, spread the calls out.

Response notes

  • Repository id is a number on some providers and a string (UUID) on others. Treat it as opaque.
  • Pull requests include draft, state, user (the author), and merged_at (null if not merged).
  • Issues include closed_at (null if open).
  • Releases include tag_name, prerelease and released_at. Not every Git host has releases.
  • Commits include author, author_email and committed_at.
  • States use the provider’s own words (open, closed, merged, opened…). Normalize them in your code if you need a fixed set.
For anything else, such as review comments, check runs or file contents, use the Proxy.