Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/org-quicko/skillset/llms.txt

Use this file to discover all available pages before exploring further.

An Integration is the Registry’s registration with a Git Provider — GitHub or GitLab. Creating an Integration is what makes the Import feature available for that provider: there is no separate toggle. Writers can then grant personal Connections through an Integration, and those Connections are what an Import uses to read a private repository. This page explains how to configure Integrations as an Admin, how they relate to Connections, and what the constraints are when removing one.
An Integration is distinct from an Identity Provider. A GitHub Identity Provider lets Users sign in with GitHub OAuth — a GitHub Integration lets writers Import Skills from GitHub repositories. The two are registered and managed entirely separately, and neither knows about the other.

​
How Integrations Work

Enables Import

Creating the first Integration for a Git Provider is the only step needed to make Import available for it. Deleting the last one makes Import unavailable again.

Writers connect through it

After an Integration exists, writers grant personal Connections through it from Settings → Connections. A Connection is what gives an Import access to a private repository.

Multiple Integrations per provider

More than one Integration may be configured for the same Git Provider — two GitHub Apps, for instance. Writers choose which one to connect through.

Admin-only

All Integration management is admin-only. Writers see only whether a connectable provider is available — they never see credentials or Integration details.

​
Creating an Integration

GitHub Integrations are registered as GitHub Apps.
1

Create a GitHub App

In your GitHub organisation settings, go to Developer settings → GitHub Apps → New GitHub App. Configure the following:
  • Callback URL: https://your-registry.example.com/api/connections/github/callback
  • Repository permissions: Contents (read) and Metadata (read)
  • User permissions: none required
  • Disable the Webhook unless you have a separate use for it
After creating the app, note the App ID, generate a private key, and record the App slug (shown in the app’s URL).
2

Register the Integration in Skillset

Go to Settings → Integrations → New Integration and fill in:
  • Provider: github
  • Display name: a label for your team, e.g. GitHub (Acme)
  • Client ID: the GitHub App’s Client ID (from its settings page)
  • Client secret: the GitHub App’s Client secret
  • App slug: the slug from the App’s URL (required for GitHub — it is used to build the repository-access management link)
3

Verify

The Integration appears in Settings → Integrations. Writers can now connect from Settings → Connections and begin Importing.
The GitHub App needs read access to Contents and Metadata on repositories. Access to specific repositories is chosen by the writer when they manage their Connection’s repository permissions.

​
API

curl -X POST https://your-registry.example.com/api/integrations \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{
    "provider": "github",
    "display_name": "GitHub (Acme)",
    "client_id": "Iv1.abc123def456",
    "client_secret": "ghp_...",
    "app_slug": "acme-skill-registry"
  }'
The client_secret is accepted on write but never returned in any response — not even to the Admin who set it. To rotate a secret, send a PATCH with the new value. To confirm the stored value, you must check the Git Provider directly.
The POST /api/integrations request body accepts:
​
provider
string
required
The Git Provider to register against. One of github or gitlab.
​
display_name
string
required
A human-readable label shown to writers when they choose which Integration to connect through. Maximum 100 characters.
​
description
string
An optional note on what this Integration is for. Maximum 180 characters.
​
client_id
string
required
The app’s Client ID at the Git Provider.
​
client_secret
string
required
The app’s client secret. Encrypted at rest; never returned in responses.
​
app_slug
string
The app’s slug at the provider, used to build the repository-access management link. Required for GitHub — omitting it prevents writers from reaching the page where they choose which repositories the Registry may read.

​
Updating an Integration

Use PATCH /api/integrations/:id to update any field except provider — which Git Provider an app is registered with does not change. 
curl -X PATCH https://your-registry.example.com/api/integrations/<id> \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{"client_secret": "ghp_new_secret_value"}'
Updating client_id repoints the Integration at a different app. This silently invalidates every writer’s Connection that was granted through the old app, because those tokens were issued to the old app’s credentials. All affected Connections are deleted in the same transaction. Writers will need to reconnect. Rotating client_secret alone does not affect Connections.

​
Connections

A Connection is a writer’s personal grant of repository access to the Registry. Once an Integration exists, writers can create a Connection from Settings → Connections by going through the Git Provider’s OAuth or App installation flow.
  • A writer holds at most one Connection per Git Provider at a time — reconnecting replaces the previous Connection rather than adding another.
  • The connected account does not have to be the same account the writer signs in with.
  • A Connection reaches only the repositories its Integration’s app was granted access to — not everything the writer can read personally.
A writer can disconnect from Settings → Connections → Disconnect. This removes the Registry’s stored copy of the grant and stops the Registry using it for future Imports. It does not revoke the grant at the Git Provider — to do that fully, the writer must also revoke the app’s access from their account settings at the provider.

​
Deleting an Integration

An Integration can be deleted from Settings → Integrations, or via DELETE /api/integrations/:id. 
curl -X DELETE https://your-registry.example.com/api/integrations/<id> \
  -H "Authorization: Bearer <token>"
Deletion is refused with 409 Conflict while any writer still holds a Connection that references the Integration. Remove all Connections first (writers can disconnect themselves, or you can ask them), then delete the Integration. Alternatively, use PATCH to repoint the Integration at a new app — this clears Connections automatically and informs writers they need to reconnect.

​
API Reference

All Integration endpoints require an admin role.
MethodPathDescription
GET/api/integrationsList all configured Integrations
POST/api/integrationsCreate a new Integration
PATCH/api/integrations/:idUpdate an Integration’s details or credentials
DELETE/api/integrations/:idDelete an Integration (refused if Connections exist)
GET/api/connectionsList own Connections and connectable providers (writer+)
GET/api/connections/:provider/startBegin the OAuth flow for a Connection (writer+)
DELETE/api/connections/:providerDisconnect from a provider (writer+)

Build docs developers (and LLMs) love

Get started for freeTalk to us