Integrations: Overview
An integration connects Vantik to a tool you already use. It does two things, and they used to be two separate systems.
- It connects: the OAuth flow, the account, the token.
- It reacts: an issue changes and the integration mirrors it out, or a webhook arrives and it mirrors something in.
Both halves live in one directory, apps/server/src/integrations/<slug>, and
ship with the server. The server loads one by the slug of its row and calls
it.
What an integration can do
An integration receives a context and asks the host to act for it. It holds no database connection, and no credential.
| Capability | What it is for |
|---|---|
issues, comments | Create and update the work |
links | The mapping between an issue and the thing it mirrors |
workspace | Teams, users, labels, workflows |
account | The connected account, and a person's own where they have one |
vendor | Calling the third party |
attachments, ai, log | Files, the model, and the log |
vendor.fetch is the one to understand. The integration says what to call;
the server attaches the credential and refuses any host the integration did not
declare. So an integration never holds a token, and where it runs can change
without the integration changing.
What ships
| Integration | What it does |
|---|---|
| GitHub | Two-way sync of issues, comments and pull requests |
| Discord | Mirrors a channel thread into an issue, and replies back out |
| Turns an email into an issue, with its attachments | |
| Bug Enricher | Suggests a resolution on an issue labelled bug. No third party |
| Local repository | A git repository on the disk of this machine |
Writing one
Integrations ship with the server, so writing one means adding a directory and opening a pull request. There is no separate deployment, no bundle to upload and no registry to publish to.
Each directory exports a pluginSpec — the slug, the hosts it may reach, and
how the server builds its credential — and a default handler that takes an event
and the context.