Anything that can post can file work.
Delatura is API-first at the edges on purpose: the queue, the permission model and the audit trail are the same whether a task came from a person, a pipeline or an alert. What differs is how much glue you write, and that is what the connectors below remove.
What is connected today
Three states, used literally. Available means you can use it now; partial means it works with us in the loop; planned means it does not exist.
Invoke API
availableAny system that can send an HTTP request can file work and stream the transcript back, with idempotency so a retrying caller does not start a second run. This is how CI, alerting and internal scripts drive agents today.
GitHub
partialRepository reads, branches and pull requests run through a GitHub App with installation-scoped tokens. Self-serve repository connect is still being wired, so onboarding a repository is done with us rather than by you.
Webhooks in
partialSignatures are verified on receipt; turning those events into tasks and mid-run steers is the next increment.
Object storage
availableRun artifacts, uploads and recordings are stored per organization, addressed by keys that cannot reach another tenant.
Sentry
plannedAlert-to-agent triage is the case we most want to ship, and it is not shipped. Until it is, the invoke API is the honest route — a webhook handler on your side takes about twenty lines.
Jira and Linear
plannedTicket-to-pull-request through the packaged connector. Same story: reachable today through the invoke API, not yet a connector you click.
Slack
plannedFiling and following work from a channel.
GitLab and Bitbucket
plannedThe source-control layer is provider-agnostic by design and only GitHub is implemented behind it. We would rather say that than list logos.
Need one that isn’t here?
Beta teams influence this order directly. Tell us which stream carries the work you actually want picked up and it moves.