| 1 | --- |
| 2 | title: Integrations |
| 3 | description: Connect the tools your team and you already use. Workspace integrations work for everyone in a workspace; personal ones work just for you, in every workspace. What is available today, what is coming, and how to ask for one. |
| 4 | --- |
| 5 | |
| 6 | g1t connects to the tools your work already lives in: where errors are |
| 7 | reported, where tickets are tracked, where code came from. Every |
| 8 | integration is listed in one directory, by category, whether it works |
| 9 | today or is still being built. The directory is **Integrations**, at |
| 10 | `g1t.sh/<workspace>/-/integrations`. |
| 11 | |
| 12 | ## Workspace and personal |
| 13 | |
| 14 | There are two places to connect things, and they are for different people: |
| 15 | |
| 16 | | | Workspace integrations | Your integrations | |
| 17 | | --- | --- | --- | |
| 18 | | Where | **Integrations**, at `g1t.sh/<workspace>/-/integrations`, with each integration's setup page under it | **Your settings → Integrations**, at [`g1t.sh/settings/integrations`](https://g1t.sh/settings/integrations) | |
| 19 | | Who it is for | Everyone in that workspace | Just you, in every workspace you belong to | |
| 20 | | Who connects | Workspace owners. Members see what is connected. | You | |
| 21 | | Examples | Your AI providers, Sentry, Jira, Linear, GitHub imports, webhooks | Signing in with GitHub, coding agents you connect through MCP, and soon your calendar | |
| 22 | |
| 23 | Some tools have both sides. GitHub, for instance: a workspace owner |
| 24 | installs g1t's GitHub App to import the team's repositories, and |
| 25 | you link your own GitHub account to sign in with it. Each card says when |
| 26 | the other side exists. |
| 27 | |
| 28 | ## The directory |
| 29 | |
| 30 | Both pages are the same directory: |
| 31 | |
| 32 | - **Categories** down the side (along the top on a phone): Code & CI, |
| 33 | Issues & projects, Chat & meetings, Calendar & email, Docs & knowledge, |
| 34 | Monitoring & incidents, Cloud & deploy, AI models, Data & analytics, CRM & support, |
| 35 | Design, Security & identity, and Files & storage. Each shows how many |
| 36 | integrations it has. A link can open on one, with `?category=code` and |
| 37 | so on. |
| 38 | - **Search** finds an integration by name, by what it does ("in a meeting", |
| 39 | "opens issues"), or by a tag, across every category. |
| 40 | - **Connected** comes first: what is set up here, with a line about each |
| 41 | (the account, how many connections) and **Needs attention** when |
| 42 | something is wrong, such as a key that stopped working or a GitHub |
| 43 | installation that was suspended. Choose one to manage it. |
| 44 | - **Available** can be connected now. Choose one to open its setup page. |
| 45 | - **Soon** is being built. Each says what it will do, and **Ask for this** |
| 46 | tells g1t you want it (below). |
| 47 | |
| 48 | The tags on a card say what an integration lets g1t do: **Opens issues**, |
| 49 | **Writes back** (the other system hears when work lands), **Imports |
| 50 | repositories**, **Sets your status**, and so on. |
| 51 | |
| 52 | ## Available today |
| 53 | |
| 54 | | Category | Workspace | Personal | |
| 55 | | --- | --- | --- | |
| 56 | | Code & CI | [GitHub](/guides/github/) import, [webhooks](/guides/webhooks/) | [Signing in with GitHub](/guides/github/#link-and-unlink-github); [MCP clients](/guides/authentication/#signing-in-with-oauth): your [coding agent](/guides/bring-your-own-agent/), connected to g1t as you | |
| 57 | | Issues & projects | [Jira and Linear](#trackers) | | |
| 58 | | Monitoring & incidents | [Sentry, Datadog, and any system that sends a webhook](#alerts) | | |
| 59 | | AI models | [Your AI providers](#your-ai-providers): Anthropic, OpenAI, Google Gemini, xAI, Mistral, DeepSeek, Azure OpenAI, OpenRouter, Groq, Together AI, Fireworks AI, Cerebras, and any Anthropic- or OpenAI-compatible endpoint | | |
| 60 | |
| 61 | AI providers, alerts and trackers each have a setup page under the |
| 62 | directory: `-/integrations/models`, `-/integrations/alerts` and |
| 63 | `-/integrations/trackers`. GitHub and webhooks |
| 64 | keep their own pages; the directory links to them. |
| 65 | |
| 66 | Secrets are sealed when they are saved and never shown again, to anyone. |
| 67 | A setup page shows the last four characters of a key, so you can tell keys |
| 68 | apart. |
| 69 | |
| 70 | ## Coming soon |
| 71 | |
| 72 | Every category has integrations on the way, among them Slack, Microsoft |
| 73 | Teams, Notion, Confluence, PagerDuty, Cloudflare, AWS, Figma, Okta and |
| 74 | Google Drive for workspaces. For you: **Google Calendar** and **Outlook |
| 75 | Calendar** will set your [status](/guides/chat/#presence-and-status) to *In a meeting* while |
| 76 | you are in one; **Zoom** |
| 77 | and **Google Meet** will set it to *On a call*. A status you set by hand |
| 78 | always wins over one an integration sets. |
| 79 | |
| 80 | The directory lists them all. Nothing on a **Soon** card does anything |
| 81 | yet. |
| 82 | |
| 83 | ## Ask for an integration |
| 84 | |
| 85 | On any **Soon** card, **Ask for this** opens an email to g1t with the |
| 86 | integration and your workspace (or "for my own account") filled in. Add |
| 87 | what you would use it for and send it. Searching for something that is |
| 88 | not listed offers the same, for whatever you searched for. Requests decide |
| 89 | what is built next. |
| 90 | |
| 91 | ## Your AI providers |
| 92 | |
| 93 | **Your AI providers**, at `g1t.sh/<workspace>/-/integrations/models`, is |
| 94 | where a workspace keeps the credentials for the AI providers its team |
| 95 | uses, so g1t can hand work to them. Only workspace owners add, test, |
| 96 | change and remove them; members see which are connected. |
| 97 | |
| 98 | - **Add one.** Choose a provider and paste its API key. Anthropic, OpenAI, |
| 99 | Google Gemini, xAI, Mistral, DeepSeek, OpenRouter, Groq, Together AI, |
| 100 | Fireworks AI and Cerebras need only the key. Azure OpenAI also needs |
| 101 | your resource's endpoint and the deployment's name. An Anthropic- or |
| 102 | OpenAI-compatible endpoint (your own gateway, LiteLLM, vLLM and the |
| 103 | like) needs its base URL over `https://`, and takes a key if it asks for |
| 104 | one, sent as `x-api-key` or `Authorization: Bearer`. You can name the |
| 105 | model your team uses on each. |
| 106 | - **Test.** g1t checks a key as it is saved, and again whenever you choose |
| 107 | **Test**, by asking the provider for its models. A key that works shows |
| 108 | how many models it offers; one that fails says why, on the connection, |
| 109 | until it next works. An endpoint that does not list its models is |
| 110 | reached, but its key cannot be checked this way. |
| 111 | - **Change.** **Change its model, address or key** sets a new model or |
| 112 | address, or replaces the key. The old key is gone once the new one is |
| 113 | saved. |
| 114 | - **Remove.** The **×** on a connection disconnects it and deletes its key. |
| 115 | |
| 116 | Keys are sealed when they are saved and never shown again, to anyone; the |
| 117 | page shows only their last four characters. |
| 118 | |
| 119 | The **Ask AI** button in the top bar is where you will start work on one |
| 120 | of these providers. It is not on yet: it shows the composer, marked |
| 121 | coming soon. |
| 122 | |
| 123 | ## Alerts |
| 124 | |
| 125 | An alert source opens issues in one repository. Each problem it reports is |
| 126 | one issue: |
| 127 | |
| 128 | - **The first alert** opens an issue labelled `bug` (or the label you set) |
| 129 | and the provider's name, with what the provider said about the problem. |
| 130 | - **The same problem again** updates that issue instead of opening another. |
| 131 | The issue says so when the count passes 10, 100, 1,000 and so on. |
| 132 | - **The same problem after its issue was closed** reopens it, with a comment |
| 133 | linking the new occurrence. |
| 134 | - **A recovery** (Datadog) is noted on the issue. |
| 135 | |
| 136 | Text in an alert can include what your users typed, such as an error |
| 137 | message built from a request. Issues opened from alerts say so. |
| 138 | |
| 139 | Each alert connection shows its last five deliveries: what arrived, and |
| 140 | whether g1t opened, updated, reopened, ignored or refused it. |
| 141 | |
| 142 | ### Sentry |
| 143 | |
| 144 | 1. On the **Integrations** page, choose **Sentry**. Give your organization's |
| 145 | slug and the repository issues go to, then **Connect**. |
| 146 | 2. In Sentry, open **Settings → Developer Settings → Custom Integrations** |
| 147 | and create an **internal integration**: |
| 148 | - **Webhook URL**: the address g1t shows on the connection, |
| 149 | `https://api.g1t.sh/hooks/<connection>`. |
| 150 | - Turn on **Alert Rule Action**, and under **Webhooks** tick **issue**. |
| 151 | - **Permissions**: Issue & Event, read and write. |
| 152 | 3. Save it. Paste its **client secret** into the connection on g1t, and its |
| 153 | **token** as the connection's auth token. |
| 154 | |
| 155 | Then: |
| 156 | |
| 157 | - New Sentry issues open g1t issues. So does any alert rule whose action |
| 158 | sends a notification to the integration. |
| 159 | - With the token, g1t adds the latest event's stack trace, in-app frames |
| 160 | first, so whoever picks it up starts at the failing line. |
| 161 | - When the fix merges, g1t resolves the Sentry issue and comments with the |
| 162 | pull request. If Sentry sees it again, the g1t issue reopens. |
| 163 | |
| 164 | Requests without a valid `Sentry-Hook-Signature` are refused. |
| 165 | |
| 166 | ### Datadog |
| 167 | |
| 168 | 1. On the **Integrations** page, choose **Datadog**, pick the repository, |
| 169 | and **Connect**. g1t shows a signing secret once; copy it. |
| 170 | 2. In Datadog, open **Integrations → Webhooks** and add a webhook named |
| 171 | `g1t`: |
| 172 | - **URL**: the connection's address. |
| 173 | - **Custom headers**: `{"Authorization": "Bearer <signing secret>"}` |
| 174 | - **Payload**: |
| 175 | |
| 176 | ```json |
| 177 | { |
| 178 | "id": "$ALERT_ID", |
| 179 | "title": "$EVENT_TITLE", |
| 180 | "body": "$EVENT_MSG", |
| 181 | "url": "$LINK", |
| 182 | "status": "$ALERT_TRANSITION", |
| 183 | "priority": "$PRIORITY" |
| 184 | } |
| 185 | ``` |
| 186 | |
| 187 | 3. Mention `@webhook-g1t` in the message of any monitor that should open |
| 188 | issues. |
| 189 | |
| 190 | A monitor that triggers opens an issue; `Recovered` is noted on it. |
| 191 | |
| 192 | ### Any other system |
| 193 | |
| 194 | The **Webhook** connection takes JSON from anything that can send it: |
| 195 | PagerDuty, Grafana, a deploy script. |
| 196 | |
| 197 | ```sh |
| 198 | body='{"id":"checkout-500","title":"Checkout returns 500 for empty carts","body":"POST /checkout fails."}' |
| 199 | curl -X POST https://api.g1t.sh/hooks/$CONNECTION \ |
| 200 | -H "Content-Type: application/json" \ |
| 201 | -H "X-G1t-Signature: sha256=$(printf '%s' "$body" | openssl dgst -sha256 -hmac "$SECRET" -hex | cut -d' ' -f2)" \ |
| 202 | -d "$body" |
| 203 | ``` |
| 204 | |
| 205 | Sign it either way: |
| 206 | |
| 207 | - `X-G1t-Signature: sha256=<hex HMAC-SHA256 of the body>`, with the signing |
| 208 | secret as the key, or |
| 209 | - `Authorization: Bearer <signing secret>`. |
| 210 | |
| 211 | g1t reads these fields, taking the first name present: |
| 212 | |
| 213 | | Field | Names | Notes | |
| 214 | | --- | --- | --- | |
| 215 | | Title | `title`, `event_title`, `summary`, `name` | Required. | |
| 216 | | Id | `id`, `alert_id`, `aggregate`, `incident_key`, `dedup_key` | Alerts with the same id are one issue. The title if missing. | |
| 217 | | Description | `body`, `message`, `event_msg`, `text`, `description` | Markdown. | |
| 218 | | Link | `url`, `link`, `html_url` | | |
| 219 | | State | `status`, `transition`, `alert_transition`, `state` | `recovered`, `resolved`, `ok` or `closed` means it stopped. | |
| 220 | | Priority | `priority`, `severity`, `level` | | |
| 221 | | Count | `count` | How many times it has happened. | |
| 222 | |
| 223 | g1t answers `202` once the request is verified and acts on it just after, |
| 224 | so a slow step never makes the sender retry. It answers `401` to a request |
| 225 | that is not signed, and `200` with the reason to one it ignores. |
| 226 | |
| 227 | ## Trackers |
| 228 | |
| 229 | Connect Jira or Linear and tickets become something people and your |
| 230 | coding agents can reach from g1t. |
| 231 | |
| 232 | ### Look up a ticket |
| 233 | |
| 234 | Give a ticket key or address (`TECH-1234`, |
| 235 | `https://acme.atlassian.net/browse/TECH-1234`, |
| 236 | `https://linear.app/acme/issue/ENG-42/…`, a Sentry issue's address) and |
| 237 | g1t fetches it from the system it lives in, with its title, status and |
| 238 | description as they are now. Your coding agent looks one up over MCP with |
| 239 | the `search` tool's `ticket` action, or through the API: |
| 240 | |
| 241 | ```sh |
| 242 | curl "https://api.g1t.sh/repos/acme/web/context?reference=TECH-1234" \ |
| 243 | -H "Authorization: Bearer $G1T_TOKEN" |
| 244 | ``` |
| 245 | |
| 246 | ### Import a ticket as an issue |
| 247 | |
| 248 | On a repository's **New issue** page, give a key or paste an address under |
| 249 | **Bring one in**. g1t opens an issue with the ticket's title and |
| 250 | description, linked to it. Importing the same ticket again opens the issue already made. |
| 251 | |
| 252 | From the API or MCP: |
| 253 | |
| 254 | ```sh |
| 255 | curl -X POST https://api.g1t.sh/repos/acme/web/issues/import \ |
| 256 | -H "Authorization: Bearer $G1T_TOKEN" -H "Content-Type: application/json" \ |
| 257 | -d '{"reference": "TECH-1234"}' |
| 258 | ``` |
| 259 | |
| 260 | An issue tied to something outside g1t shows it under **From outside g1t**, |
| 261 | with a link to the original. |
| 262 | |
| 263 | ### Tickets hear back |
| 264 | |
| 265 | Unless you turn it off, g1t comments on the ticket when a pull request |
| 266 | opens for its issue, and again when the issue closes as done, with a link |
| 267 | to what merged. For Sentry, closing as done resolves the Sentry issue. |
| 268 | |
| 269 | ### Jira |
| 270 | |
| 271 | | Setting | | |
| 272 | | --- | --- | |
| 273 | | Site | Your Jira's address, such as `https://acme.atlassian.net`. | |
| 274 | | Email | The Atlassian account the API token belongs to. | |
| 275 | | API token | From id.atlassian.com, **Security → API tokens**. g1t sees what that account can see. | |
| 276 | | Project keys | Optional. The projects this connection answers for, such as `TECH, OPS`. Empty answers for any key. | |
| 277 | |
| 278 | ### Linear |
| 279 | |
| 280 | | Setting | | |
| 281 | | --- | --- | |
| 282 | | API key | From Linear, **Settings → Security & access → Personal API keys**. | |
| 283 | | Team keys | Optional, such as `ENG`. Empty answers for any key. | |
| 284 | |
| 285 | A key that matches several connections is looked up in the ones that name |
| 286 | its project first. |
| 287 | |
| 288 | ## From the API |
| 289 | |
| 290 | Owners can manage integrations through the API and MCP, with a person's |
| 291 | token (a workspace token cannot): |
| 292 | |
| 293 | | MCP tool and action | Route | |
| 294 | | --- | --- | |
| 295 | | `workspace` `list_integrations` | `GET /workspaces/{workspace}/integrations` | |
| 296 | | `workspace` `connect_integration` | `POST /workspaces/{workspace}/integrations` | |
| 297 | | `workspace` `update_integration` | `PATCH /workspaces/{workspace}/integrations/{id}` | |
| 298 | | `workspace` `test_integration` | `POST /workspaces/{workspace}/integrations/{id}/test` | |
| 299 | | `workspace` `disconnect_integration` | `DELETE /workspaces/{workspace}/integrations/{id}` | |
| 300 | | `search` `ticket` | `GET /repos/{owner}/{name}/context?reference=` | |
| 301 | | `issue` `import` | `POST /repos/{owner}/{name}/issues/import` | |
| 302 | |
| 303 | ```sh |
| 304 | curl -X POST https://api.g1t.sh/workspaces/acme/integrations \ |
| 305 | -H "Authorization: Bearer $G1T_TOKEN" -H "Content-Type: application/json" \ |
| 306 | -d '{"provider": "jira", "config": {"site": "https://acme.atlassian.net", "email": "dev@acme.com", "keys": ["TECH"]}, "secret": "<api token>"}' |
| 307 | ``` |
| 308 | |
| 309 | `provider` is an AI provider (`anthropic`, `openai`, `gemini`, `xai`, |
| 310 | `mistral`, `deepseek`, `azure_openai`, `openrouter`, `groq`, `together`, |
| 311 | `fireworks`, `cerebras`, `anthropic_endpoint` or `openai_endpoint`), or |
| 312 | `sentry`, `datadog`, `webhook`, `jira` or `linear`. `config` takes `repo`, |
| 313 | `label`, `write_back`, `organization`, `site`, `email` and `keys`, and for |
| 314 | an AI provider `base_url`, `auth_header` and `model`; each provider uses |
| 315 | the ones above. For `datadog` |
| 316 | and `webhook`, the response's `signing_secret` is the only time the secret |
| 317 | is shown. |