Repository API Integration: Repositories, Pull Requests, and Commit Activity Across Git Platforms

February 12, 2026

Repository data is where software delivery becomes observable. Repositories change, commits land, branches move, pull requests shift state, and ownership lives in review queues. When repo data is fragmented across GitHub, GitLab, and Bitbucket—or pulled through delayed sync—teams lose visibility into review bottlenecks, contribution patterns, and release readiness.

Repository API integration exists to solve this problem.

In this guide, we'll explain what a Repository API covers, which objects matter in practice, how repo lifecycles behave, how updates are delivered, and how Unified's Repository API fits alongside Tasks, Ticketing, Knowledge Management, and File Storage in the Knowledge & Development group.

Introduction to Repository API Integrations

Version control platforms such as GitHub, GitLab, and Bitbucket store the core objects behind modern development:

• Organizations and workspaces
• Repositories
• Branches and commit history
• Pull requests and merge requests
• Review state, labels, and closure timestamps

Each provider models these objects differently. Even basic concepts—what counts as an organization, how PR status is represented, which list filters exist—vary enough that supporting multiple providers becomes ongoing maintenance.

A Repository API provides a consistent way to read repository metadata and activity across providers without building separate integrations.

What Is a Repository API?

A Repository API allows applications to programmatically access repository and code review metadata, including:

• Organizations (orgs, groups, workspaces)
• Repositories
• Branches
• Commits (metadata and authorship)
• Pull requests (state, labels, closure)

Repository APIs focus on version control objects and review state. They do not replace task tracking, support ticketing, file storage, documentation systems, or generative model execution.

Repository API vs Tasks, Ticketing, KMS, Storage, and GenAI

Unified keeps category boundaries explicit.

• Repository covers organizations, repositories, branches, commits, and pull requests.
• Tasks covers tasks, projects, and work tracking objects.
• Ticketing covers tickets, customers, notes, and categories.
• KMS covers spaces, pages, and comments for knowledge content.
• Storage covers files and folders across cloud storage providers.
• GenAI covers models, embeddings, prompts, and generation.

Repository objects don't embed task IDs, ticket IDs, page IDs, or file IDs. If your product needs cross-domain views, you compose categories intentionally.

Real-Time Access to Repository Data

Unified routes each Repository API request directly to the source provider. There is no cached replica. Reads reflect the provider's current state, subject to rate limits and availability.

Update delivery depends on provider support. Some objects can be monitored through virtual webhook delivery; others require polling.

Core Repository Data Models

Unified normalizes repository data into five objects: Organization, Repository, Branch, Commit, and Pullrequest.

Organizations

Organizations represent top-level containers like GitHub orgs or GitLab groups.

Common fields include:

• id, created_at, updated_at
• name, description
• avatar_url, web_url
• user_ids

Repositories

Repositories represent code repositories inside an organization.

Common fields include:

• id, created_at, updated_at
• name, description
• owner, is_private
• web_url
• org_id

Branches

Branches represent Git branches.

Common fields include:

• id, created_at, updated_at
• name
• repo_id

Commits

Commits represent Git commits.

Common fields include:

• id (commit hash)
• created_at, updated_at
• user_id
• repo_id, branch_id
• message

Unified returns commit metadata. Code diffs and file contents are not part of the normalized commit object.

Pull Requests

Pull requests represent pull requests or merge requests.

Common fields include:

• id, created_at, updated_at
• repo_id
• user_ids
• status (PENDING, APPROVED, REJECTED)
• labels
• closed_at
• commit_ids

Identity and Ownership in Repository Data

Repository objects are provider-scoped and connection-scoped.

• org_id, repo_id, branch_id, and commit_ids link objects within the repository domain.
• Commit and pull request IDs are stable within the provider namespace.
• user_id and user_ids identify participants and can be mapped to employee identity where applicable.

Repository objects do not reference tasks, tickets, knowledge pages, storage files, CRM contacts, or GenAI artifacts.

Object Behavior and Lifecycle Semantics

Repository objects behave like the underlying Git model:

• Commits are immutable snapshots. Updating or deleting a commit generally implies rewriting history, which is destructive and not a standard integration pattern.
• Pull requests become terminal once closed. closed_at captures closure time and status transitions stop.
• Branch deletion removes the branch reference but not the commits.
• Repository deletion is irreversible.

Unified surfaces lifecycle timestamps (created_at, updated_at, and closed_at where applicable) as recorded by the provider.

Write Support and Provider Behavior

Unified's Repository API defines CRUD-style endpoints for repository objects. In practice, the GitHub, GitLab, and Bitbucket integrations currently operate as read-focused surfaces for core objects:

• Organizations: list and retrieve
• Repositories: list and retrieve
• Branches: list and retrieve
• Commits: list and retrieve
• Pull requests: list and retrieve

If your use case requires creating repositories, managing branches, or closing pull requests through an API, confirm provider-level support before building workflows around writes.

Updates, Webhooks, and Polling

Repository platforms differ in what can be monitored efficiently.

Webhooks

For repository integrations, webhook delivery is virtual-only.

• Commit events: created and updated are supported through virtual webhook delivery.
• Repository events: created and updated are supported through virtual webhook delivery.
• Branch, pull request, and organization objects do not emit webhook events.

Virtual webhook delivery does not include delete events. Deletion detection requires periodic reconciliation.

Polling

Polling support varies by provider and object.

• Commit lists: updated_gte is available for GitHub and GitLab, not available for Bitbucket.
• Repository and pull request lists: updated_gte is not available, so polling requires full list reads with sorting by update time.
• Branch lists: updated_gte exists for GitHub branch lists, not for GitLab and Bitbucket.

When incremental filters aren't available, polling relies on:

• sorting by updated_at
• storing the newest updated_at you've processed
• deduplicating by stable IDs

Deletions

Virtual webhook delivery does not emit delete events. If you need deletion visibility (e.g., repository removed), periodically list and reconcile IDs against your stored state.

Security, Data Handling, and Compliance

Repository data is sensitive even when you are not fetching source code.

Zero-storage design

Unified does not store end-customer repository payloads at rest.

• Requests are routed directly to the provider
• No cached replica
• No stored repository payload database

What is returned

The normalized schema focuses on metadata:

• repository names and visibility flags
• commit messages and authorship references
• pull request state, labels, and closure timestamps
• organization metadata and membership IDs

Code diffs and file contents are not returned in the normalized objects.

Sensitivity considerations

• Commit messages can contain secrets or internal context.
• Labels can reveal internal workflow classification.
• Repository visibility (is_private) reflects access boundaries.
• raw can include provider-specific fields and should be requested only when needed.

Common Repository API Integration Use Cases

Development analytics

Track commit volume, pull request velocity, review state distribution, and closure trends across providers.

Cross-platform code review tools

Display PR state, participants, labels, and closure timestamps across GitHub, GitLab, and Bitbucket.

Repository inventory

Aggregate repository lists across organizations and surface visibility, ownership, and metadata.

Release readiness signals

Use commit and PR activity as inputs to release dashboards, without building per-provider logic.

Constraints to Design Around

• Provider parity is uneven across objects.
• Commits are effectively immutable.
• Pull requests become terminal on close.
• Only commits and repositories emit webhook events.
• [Virtual webhooks](/blog/unlock_real_time_data_with_virtual_webhooks) do not include delete events.
• Incremental polling support varies by object and provider.

These are provider realities and should be incorporated into system design.

Build vs Maintain Repository Integrations

Building in-house

• Separate provider APIs
• Different object shapes and filters
• Provider-specific event delivery and pagination behavior
• Ongoing maintenance as providers evolve

Using a Unified Repository API

• One category-scoped API for repository objects
• Standard fields for orgs, repos, branches, commits, and pull requests
• Live reads from source providers
• Clear boundaries with tasks, tickets, knowledge, and storage

Build repository integrations without duplicate provider logic

If your product needs repository visibility across GitHub, GitLab, and Bitbucket, maintaining separate integrations becomes expensive quickly.

Unified's Repository API provides a consistent way to access repositories, branches, commits, and pull request state across providers without storing repository data at rest.

→ Start your 30-day free trial

→ Book a demo

FAQ

What objects does the Repository API expose?

Organizations, repositories, branches, commits, and pull requests.

Does the API return code diffs or file contents?

No. The normalized objects return metadata, not repository file content.

Can I create repositories or pull requests through the API?

Provider support varies. For GitHub, GitLab, and Bitbucket, core repository objects are currently read-focused.

How are updates delivered?

Commits and repositories support virtual webhook delivery. Other objects rely on polling.

Does Unified store repository data at rest?

No. Repository payloads are not stored at rest.