Everything an AI agent can do with the Gitea API.

A reference guide for building AI agents: every method, how to authenticate, and the permissions each one needs.

Endpoints41
API versionv1
Last updated23 June 2026
Orientation

How the Gitea API works.

The Gitea API is how an app or AI agent works with a Gitea instance: reading and creating repositories, filing and editing issues, opening and merging pull requests, and reading or writing files in a repository. Access is granted through an access token sent in an Authorization header, and each token carries scopes that decide which areas it can read or write, so an agent is limited to the repositories and accounts that token reaches. Gitea can also push events to a webhook URL when something happens in a repository.

41Endpoints
11Capability groups
20Read
21Write
7Permissions
Authentication
Every write and most private reads need an access token. The token is sent as 'Authorization: token ', a header format Gitea keeps for historical reasons, or as a 'token' or 'access_token' query parameter; OAuth2 tokens may instead use 'Authorization: bearer '. Basic authentication and signed SSH requests are also supported. Tokens are created through the API or in the user settings UI.
Permissions
An access token carries scopes that gate which areas it can reach, each available as a read or write variant: read:repository and write:repository, read:issue and write:issue, read:user and write:user, read:organization and write:organization, plus read:package, read:notification, read:misc, read:activitypub, and an admin scope for instance administration. A scope of all grants read and write across everything. Granular scopes were added in Gitea 1.19 and extended in later releases.
Versioning
The API has a single version, v1, served under a stable base path. Gitea does not mint a new API version for changes; new methods and fields arrive with each Gitea server release, and breaking changes are listed in that release's notes. An integration tracks the Gitea server version it runs against rather than an API version string.
Data model
The API is resource-oriented JSON over HTTPS, served at the /api/v1 path of a Gitea instance. Core resources nest under /repos/{owner}/{repo}, covering issues, pulls, branches, commits, contents, releases, and hooks, while others live at the account level, such as /user, /users/{username}, and /orgs/{org}. Because Gitea is self-hosted, the host is the team's own instance rather than a single shared cloud.
Connect & authenticate

Connection & authentication methods.

How an app or AI agent connects to Gitea determines what it can reach. The main route is the REST API, and an official MCP server wraps the same operations for agents, each governed by the access token behind it and the scopes that token carries.

Ways to connect

REST API

The REST API answers under the /api/v1 path of a Gitea instance and returns JSON. It is the main route for an app or AI agent, and a Swagger explorer is served at /api/swagger on the instance.

Best forConnecting an app or AI agent to Gitea.
Governed byThe access token and the scopes it carries.
Docs ↗

MCP server (Model Context Protocol)

The Gitea project maintains an official MCP server at gitea.com/gitea/gitea-mcp. It lets an agent call Gitea through the Model Context Protocol over standard input and output or over HTTP, authenticating with a Gitea access token, and covers repositories, issues, pull requests, files, releases, and organization tools.

Best forConnecting an app or AI agent to Gitea.
Governed byThe access token and the scopes it carries.
Docs ↗

Webhooks

Webhooks deliver the chosen events to a receiver URL registered on a repository, such as a push or a pull request opening, so an integration is notified instead of polling. A secret on each hook lets the receiver confirm a delivery came from the instance.

Best forReceiving repository events in an app or AI agent.
Governed byThe access token and the scopes it carries.
Docs ↗
Authentication

Access token

A personal access token is the standard way to authenticate. It carries a chosen set of read and write scopes, so it can be limited to only the areas an integration needs, and it is sent in the Authorization header on each request.

TokenPersonal access token
Best forLeast-privilege access for an integration or agent
Docs ↗

OAuth2

Gitea is an OAuth2 provider, so an app can obtain a token on behalf of a user through an authorization flow. The resulting token is sent as a bearer token and, in recent releases, can request granular scopes rather than full access.

TokenOAuth2 bearer token
Best forApps acting on behalf of a signed-in user
Docs ↗

Basic authentication

HTTP basic authentication with a username and password is supported, mainly to create the first access token. A token-based method is preferred for ongoing API use.

TokenUsername and password
Best forBootstrapping the first token
Docs ↗
Capability map

What an AI agent can do in Gitea.

The Gitea API is split into areas an agent can act on, such as repositories, issues, pull requests, file contents, releases, and webhooks. Each area maps to its own token scope, and some grant access to far more than others.

Repositories

7 endpoints

List the repositories an account owns or an organization owns, read a single repository, create one for the current user or an organization, edit a repository's settings, and delete a repository.

Deleting a repository here removes it and its history.
View endpoints

Issues

5 endpoints

List, read, create, and edit issues in a repository, and list and create their comments.

Writes here change real issue data.
View endpoints

Pull requests

5 endpoints

List, read, create, and edit pull requests, and merge a pull request into its base branch.

Merging here commits to the base branch.
View endpoints

Branches

3 endpoints

List a repository's branches, read a single branch, create a branch, and delete a branch.

Deleting a branch here removes it from the repository.
View endpoints

Commits

2 endpoints

List the commits on a repository and read a commit's combined status by branch, tag, or commit reference.

Writes here change real commit data.
View endpoints

File contents

4 endpoints

Read a file's contents at a path, create a file, update a file, and delete a file in a repository.

Writes here commit changes to repository files.
View endpoints

Releases

3 endpoints

List a repository's releases, read the latest release, and create a release.

Writes here change real release data.
View endpoints

Labels & milestones

4 endpoints

List and create a repository's labels, and list and create its milestones.

Writes here change real label and milestone data.
View endpoints

Webhooks

3 endpoints

List a repository's webhooks, create one, and delete one.

Writes here change which events are delivered and where.
View endpoints

Users

2 endpoints

Read the authenticated user's profile and read another user's profile by username.

Writes here change real user data.
View endpoints

Organizations

3 endpoints

List the authenticated user's organizations, read an organization's details, and edit its settings.

Writes here change real organization data.
View endpoints
Endpoint reference

Every Gitea API method.

Filter by method, access, or permission, or search any path. Select a row for version detail, rate limits, the related webhook event, and the source.

MethodEndpointWhat it doesAccessPermissionVersion

Repositories

List the repositories an account owns or an organization owns, read a single repository, create one for the current user or an organization, edit a repository's settings, and delete a repository.7

Returns only the repositories the token's account owns. The read:repository scope covers read methods across the repository area.

Acts onrepository
Permission (capability)read:repository
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Private repositories appear only when the token's account can see them.

Acts onrepository
Permission (capability)read:repository
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Returns 404 rather than 403 for a private repository the token cannot see.

Acts onrepository
Permission (capability)read:repository
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Creating a repository needs the write:repository scope.

Acts onrepository
Permission (capability)write:repository
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

The account must have rights to create repositories in the organization.

Acts onrepository
Permission (capability)write:repository
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Changes settings such as the description, default branch, and feature toggles.

Acts onrepository
Permission (capability)write:repository
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Removes the repository and its history; the account must own or administer it.

Acts onrepository
Permission (capability)write:repository
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Issues

List, read, create, and edit issues in a repository, and list and create their comments.5

Pull requests can also be returned here, filtered through the type parameter.

Acts onissue
Permission (capability)read:issue
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

The index is the issue number within the repository.

Acts onissue
Permission (capability)read:issue
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Creating an issue needs the write:issue scope.

Acts onissue
Permission (capability)write:issue
VersionAvailable since the API’s base version
Webhook eventissues
Rate limitStandard limits apply

Closing and reopening use the state field here.

Acts onissue
Permission (capability)write:issue
VersionAvailable since the API’s base version
Webhook eventissues
Rate limitStandard limits apply

The same endpoint serves pull request conversation comments.

Acts oncomment
Permission (capability)write:issue
VersionAvailable since the API’s base version
Webhook eventissue_comment
Rate limitStandard limits apply

Pull requests

List, read, create, and edit pull requests, and merge a pull request into its base branch.5

Pull requests live in the repository area, so they use the repository scope.

Acts onpull request
Permission (capability)read:repository
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

The index is the pull request number within the repository.

Acts onpull request
Permission (capability)read:repository
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Opens a pull request from a head branch into a base branch.

Acts onpull request
Permission (capability)write:repository
VersionAvailable since the API’s base version
Webhook eventpull_request
Rate limitStandard limits apply

Closing and reopening use the state field here.

Acts onpull request
Permission (capability)write:repository
VersionAvailable since the API’s base version
Webhook eventpull_request
Rate limitStandard limits apply

Merging commits to the base branch. Returns 405 when the pull request is not mergeable.

Acts onpull request
Permission (capability)write:repository
VersionAvailable since the API’s base version
Webhook eventpull_request
Rate limitStandard limits apply

Branches

List a repository's branches, read a single branch, create a branch, and delete a branch.3

Branches live in the repository area, so they use the repository scope.

Acts onbranch
Permission (capability)read:repository
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

A new branch can be created from an existing branch.

Acts onbranch
Permission (capability)write:repository
VersionAvailable since the API’s base version
Webhook eventcreate
Rate limitStandard limits apply

A protected branch cannot be deleted through the API.

Acts onbranch
Permission (capability)write:repository
VersionAvailable since the API’s base version
Webhook eventdelete
Rate limitStandard limits apply

Commits

List the commits on a repository and read a commit's combined status by branch, tag, or commit reference.2

Can be filtered by branch, path, or author.

Acts oncommit
Permission (capability)read:repository
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Combines the statuses reported against a commit into one overall state.

Acts oncommit
Permission (capability)read:repository
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

File contents

Read a file's contents at a path, create a file, update a file, and delete a file in a repository.4

Returns the file's content base64-encoded along with its metadata.

Acts onfile
Permission (capability)read:repository
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Commits a new file with base64-encoded content to a branch.

Acts onfile
Permission (capability)write:repository
VersionAvailable since the API’s base version
Webhook eventpush
Rate limitStandard limits apply

The existing file's sha must be supplied so the commit applies to the right version.

Acts onfile
Permission (capability)write:repository
VersionAvailable since the API’s base version
Webhook eventpush
Rate limitStandard limits apply

The file's sha must be supplied, and the deletion is committed to a branch.

Acts onfile
Permission (capability)write:repository
VersionAvailable since the API’s base version
Webhook eventpush
Rate limitStandard limits apply

Releases

List a repository's releases, read the latest release, and create a release.3

Releases live in the repository area, so they use the repository scope.

Acts onrelease
Permission (capability)read:repository
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Returns the most recent published release.

Acts onrelease
Permission (capability)read:repository
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

A release is tied to a git tag, which can be created with it.

Acts onrelease
Permission (capability)write:repository
VersionAvailable since the API’s base version
Webhook eventrelease
Rate limitStandard limits apply

Labels & milestones

List and create a repository's labels, and list and create its milestones.4

Labels are part of the issue area, so they use the issue scope.

Acts onlabel
Permission (capability)read:issue
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

A label has a name and a color, and can then be applied to issues.

Acts onlabel
Permission (capability)write:issue
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Milestones are part of the issue area, so they use the issue scope.

Acts onmilestone
Permission (capability)read:issue
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

A milestone groups issues and pull requests toward a target.

Acts onmilestone
Permission (capability)write:issue
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Webhooks

List a repository's webhooks, create one, and delete one.3

Webhooks live in the repository area, so they use the repository scope.

Acts onwebhook
Permission (capability)read:repository
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Registers a receiver URL and the events to deliver, with an optional secret.

Acts onwebhook
Permission (capability)write:repository
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Stops further deliveries for the removed hook.

Acts onwebhook
Permission (capability)write:repository
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Users

Read the authenticated user's profile and read another user's profile by username.2

Identifies the account the token belongs to.

Acts onuser
Permission (capability)read:user
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Returns the public profile fields for the named user.

Acts onuser
Permission (capability)read:user
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Organizations

List the authenticated user's organizations, read an organization's details, and edit its settings.3

Returns the organizations the token's account is a member of.

Acts onorganization
Permission (capability)read:organization
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Returns the organization's public profile and settings the account can see.

Acts onorganization
Permission (capability)read:organization
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

The account must administer the organization.

Acts onorganization
Permission (capability)write:organization
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply
No endpoints match those filters.
Webhooks

Webhook events.

Gitea can notify an app or AI agent when something happens in a repository, instead of the app repeatedly asking. Gitea posts the event payload to a webhook URL that has been registered on the repository for the chosen events, such as a push or a new pull request.

EventWhat it signalsTriggered by
pushFires when one or more commits are pushed to a branch of a repository.In-app only
issuesFires on activity on an issue, such as opened, edited, closed, reopened, assigned, or labeled./repos/{owner}/{repo}/issues
/repos/{owner}/{repo}/issues/{index}
issue_commentFires when a comment is created, edited, or deleted on an issue or a pull request./repos/{owner}/{repo}/issues/{index}/comments
pull_requestFires on activity on a pull request, such as opened, edited, closed, reopened, or merged./repos/{owner}/{repo}/pulls
/repos/{owner}/{repo}/pulls/{index}
/repos/{owner}/{repo}/pulls/{index}/merge
releaseFires when a release is published, updated, or deleted in a repository./repos/{owner}/{repo}/releases
createFires when a branch or tag is created in a repository./repos/{owner}/{repo}/branches
deleteFires when a branch or tag is deleted in a repository./repos/{owner}/{repo}/branches/{branch}
No events match that search.
Rate limits & pagination

Rate limits, pagination & request size.

Gitea is self-hosted software, so how fast and how much an app or AI agent can call depends on the instance. There is no fixed request quota in the API itself, and pagination caps how many items each list call returns.

Request rate

Gitea is self-hosted, so there is no fixed request quota set by the API itself. Each instance decides its own ceilings, and an administrator can place rate limiting in front of Gitea at the reverse proxy or with the instance configuration. An integration cannot assume a published per-hour limit the way a hosted API would set one; the effective limit is whatever the instance and its operator allow.

Pagination

List endpoints page through the page parameter, which is 1-based, and the limit parameter for the page size. A Link response header carries the next, previous, and last page URLs when more than one page exists, and the X-Total-Count header reports the total number of items. The default and maximum page size are set per instance, so an integration should follow the Link header rather than assume a fixed size.

Request size

Requests and responses are JSON. List sizes are bounded by the per-instance page-size limit, and file contents and attachment endpoints are subject to the instance's configured maximum blob and upload sizes. There is no single fixed payload limit across the API, since each instance sets its own.

Errors

Status codes & error handling.

The status codes an agent should handle, and what to do about each.

StatusCodeMeaningWhat to do
401UnauthorizedAuthentication is missing or the access token is invalid or expired.Send a valid token in the Authorization header, and check it has not been revoked.
403ForbiddenThe request is authenticated but the token lacks the scope or the account lacks the permission for this action, such as a read-only token attempting a write.Grant the token the required scope, such as write:repository or write:issue, or use an account with access.
404Not FoundThe resource does not exist, or the token cannot see a private resource. Gitea returns 404 rather than 403 for a private repository the token cannot access, so it does not confirm the repository exists.Confirm the owner and repository in the path, and that the token has access to it.
409ConflictThe request conflicts with the current state, such as merging a pull request that is not mergeable or creating something that already exists.Refetch the current state and retry once the conflict is resolved.
422Unprocessable EntityValidation failed: the request was well-formed but a field is missing or invalid. The response body holds a message describing the problem.Read the message field, correct the named field, and resend.
Versioning & freshness

Version history.

The Gitea API has a single version, v1, served under a stable path. New methods and fields ship with each Gitea server release rather than through a new API version, and breaking changes are called out in the release notes.

Version history

What changed, and when

Latest versionv1
v1Current version
The single, stable API version

Gitea serves one API version, v1, under a stable base path. Rather than minting a new API version for changes, Gitea ships new methods and fields with each server release and notes breaking changes in that release's changelog. The version below is the current API version, and the timeline lists notable server releases that changed the API.

What changed
  • One API version, v1, served under a stable /api/v1 path
  • Granular token scopes (read:repository, write:issue, and so on) introduced in Gitea 1.19
  • A Swagger explorer served at /api/swagger on each instance
2026-05
Gitea 1.26 server release

Gitea 1.26.0 was the largest release in the project's history, with API changes among them. Breaking changes for integrations include corrected Swagger annotations for enums, status codes, and notification state, and the removal of the GET registration-token method. The page list size for unadopted repositories was bounded to avoid unbounded responses. Patch releases 1.26.3 and 1.26.4 followed.

What changed
  • Removed the GET API method for the registration token
  • Corrected Swagger annotations for enums, status codes, and notification state
  • Bounded the page size when listing unadopted repositories
2025-08
Gitea 1.25 server release

Gitea 1.25.0 continued to extend the API alongside server features. New methods and fields shipped with the release, following the project's model of evolving the v1 API through server releases rather than a new API version.

What changed
  • Added and extended API methods alongside new server features
  • Continued the model of evolving v1 through server releases

An integration tracks the Gitea server version it runs against, since newer methods appear as the server is upgraded.

Gitea changelog ↗
Questions

Gitea API, answered.

How do I authenticate to the Gitea API?+
Create an access token in the user settings, or through the API, then send it on each request. The usual form is the header 'Authorization: token ', which Gitea keeps for historical reasons; a token can also be passed as a 'token' or 'access_token' query parameter, and an OAuth2 token may use 'Authorization: bearer '. Basic authentication with a username and password is supported too, mainly for creating the first token.
What are the token scopes, and how granular are they?+
A token is granted scopes that gate which areas it can reach, each as a read or write variant, such as read:repository, write:repository, read:issue, write:issue, read:user, write:user, read:organization, and write:organization, plus read:package, read:notification, read:misc, read:activitypub, and admin. A read scope allows the GET methods in that area, and a write scope adds the create, edit, and delete methods. The scope of all grants read and write everywhere. Granular scopes arrived in Gitea 1.19 and were extended in later releases.
Does the Gitea API have rate limits?+
Gitea is self-hosted, so the API itself sets no fixed per-hour quota. Each instance decides its own limits, and an administrator can add rate limiting at the reverse proxy or through the instance configuration. An integration should not assume a published cloud-style limit, and should handle being throttled by the instance in front of it.
How does versioning work?+
There is one API version, v1, served under a stable path. Gitea does not release a new API version for changes; new methods and fields ship with each Gitea server release, and breaking changes are noted in that release's changelog. An integration tracks which Gitea server version it runs against, because the available methods follow the server, not a separate API version number.
Is there an official MCP server for Gitea?+
Yes. The Gitea project maintains an MCP server at gitea.com/gitea/gitea-mcp that lets an AI agent call Gitea through the Model Context Protocol. It runs over standard input and output or over HTTP, authenticates with a Gitea access token, and covers repositories, branches and tags, issues and comments, pull requests and reviews, file operations, releases, and organization tools.
How do I receive events instead of polling?+
Register a webhook on a repository and choose the events to receive, such as a push or a new or updated pull request. Gitea then posts a JSON payload to the webhook URL when each event fires, so an integration is notified rather than polling the REST API. The same hook endpoints let an integration list, create, edit, test, and delete a repository's webhooks.
Related

More developer API guides for agents

What is Bollard AI?

Control what every AI agent can do in Gitea.

Bollard AI sits between a team's AI agents and Gitea. Grant each agent exactly the access it needs, read or write, resource by resource, and every call is checked and logged.

  • Set read, write, or full access per agent, never a shared Gitea token.
  • Denied by default, so an agent reaches only what has been explicitly allowed.
  • Every call recorded in plain English: who, what, where, and the decision.
Gitea
Dev Agent
Read repositories ResourceOffReadFull use
Open and merge pull requests ActionOffReadFull use
Write repository files ResourceOffReadFull use
Manage webhooks ResourceOffReadFull use
Per-agent access, set in Bollard AI, not in Gitea