---
title: "Introduction"
description: "Learn what forges does, which forges it supports and what you can build with it."
canonical_url: "https://forges.link/getting-started/introduction"
---
# Introduction

> Learn what forges does, which forges it supports and what you can build with it.

`forges` is a TypeScript library for working with issues, pull requests, notifications, checks and webhooks on ten forges. A forge is a service that hosts Git repositories together with the collaboration around them, such as GitHub, GitLab or Codeberg.

Every forge has its own API, with its own endpoints, its own way of authenticating and its own idea of what an issue or a review looks like. `forges` hides those differences behind one data model, so you write your code once and it works on every forge. A provider for each forge takes care of the endpoints, pagination, authentication and rate limits behind the scenes. Because forges don't all offer the same features, each provider also declares which operations it supports, which lets your code find out what is available before it asks a forge for something it can't do.

## Supported forges

`forges` supports GitHub, GitLab, Bitbucket Cloud, Forgejo, Gitea, Gitee, Azure DevOps, Cursor Origin, Tangled and Pushin.eu. It also reads repositories and their contents from Git hosts with no issues or pull requests, such as Cloudflare Artifacts. Each of them has a [provider page](https://forges.link/providers) that explains how to authenticate and describes anything that behaves differently on that forge.

## What you can build

Since every forge looks the same to your code, `forges` is a good fit for tools that need to work with more than one of them. For example, you could build:

- A notification inbox that merges the notifications from GitHub, GitLab and Forgejo into one list.
- A bot that labels new issues and closes threads when someone writes a command in a comment.
- A release digest that summarises the releases of repositories hosted on different forges.
- A webhook receiver that turns the deliveries from any forge into a single event type.

The [examples](https://forges.link/examples) include small, tested projects for the first three. `forges` also ships an in-memory forge, so you can test a tool like this without making a single network request.

## How it works

Working with `forges` follows the same few steps on every forge. You start by calling a provider function such as `github()` with your options. This doesn't send any request. It returns a factory that remembers the options, and calling `create()` on that factory gives you the provider, which is the object you work with from then on. If you target several forges, `createForges()` does the same for a whole list of factories and combines the providers into one object.

A provider groups its operations into namespaces such as `threads`, `notifications`, `checks` and `webhooks`. Each operation also has an entry in the provider's capabilities, which describe how well that forge supports it. Before you call an operation that a forge might lack, you can ask `provider.can()` whether it is available.

## Next steps

<card-group>
<card icon="i-lucide-download" title="Installation" to="https://forges.link/getting-started/installation">

Add the package and pick an import path.

</card>

<card icon="i-lucide-terminal" title="Quick start" to="https://forges.link/getting-started/quick-start">

Read an issue, write a comment and add a second forge.

</card>

<card icon="i-lucide-shapes" title="Data model" to="https://forges.link/concepts/data-model">

Learn how refs, threads and events fit together.

</card>

<card icon="i-lucide-server" title="Providers" to="https://forges.link/providers">

Find the authentication options for your forge.

</card>
</card-group>


## Sitemap

See the full [sitemap](https://forges.link/sitemap.md) for all pages.
