# Integrations

> Connect GitHub, Slack, accounts, project email, previews, and hosted worker logs to your darting project.

Connections here serve different jobs: GitHub keeps code and pull requests in step, Slack sends announcements, connected accounts let agents work with services you authorize, and project email helps with sign-up and verification flows. A hosted app has its own deployment and logs. These are not interchangeable ways for an outside script to start or stream a thread.

## GitHub activity

Connect a repository to give each thread its own working branch and [Ship it](https://darting.dev/docs/ship-it-and-pull-requests/) path to a pull request. Signed **GitHub webhooks** tell darting when the default branch or a thread branch has moved, when checks change, and when PRs open, update, or merge. A default-branch push also prompts the platform to refresh deployment and branch state; dependency-input changes can refresh the project's sandbox snapshot. Deployment-status events let a tracked external deployment show its progress. The project feed records relevant PR, deployment, and review activity.

A webhook delivery is an observation about the repository, **not a general-purpose thread-command endpoint**: posting an issue comment does not automatically create a new agent thread. [GitHub & authentication](https://darting.dev/docs/github-and-auth/) covers access to the repo, and [update from main](https://darting.dev/docs/update-from-main/) covers the thread side of branch movement.

## Project email and Slack

A project can obtain an **inbox address** for mail used during account-creation flows. Incoming mail is delivered to that address and can be read by the project's agent, including verification codes needed to complete a sign-up. This is an email inbox, not an arbitrary event POST for automations. The address is available when inbound email is configured on the service.

In Project settings → **Connections**, you can connect a Slack channel for **merge announcements**. The integration posts updates to the chosen channel; it does not read Slack messages or turn them into agent prompts. You can pause announcements, send a test, or disconnect the channel there.

## Accounts and previews

Project connections can also include third-party accounts that agents use with your permission. Connection and approval happen through the app, not by pasting credentials into a thread. A write through a connected account can require your explicit approval before it runs. [The vault & login browser](https://darting.dev/docs/vault-and-login-browser/) explains account connections, the isolated sign-in browser, and vaulted keys.

A running thread's app can be opened in the workspace or through its **share link**. That link proxies the thread's sandbox preview and can wake a sleeping sandbox on a direct visit; it is useful for testing and showing work in progress. It is not the same as the always-on production address you get from [hosting on darting.app](https://darting.dev/docs/hosting/), which builds merged code from the default branch. Media deliberately attached to a pull request can also be shown there through a shareable media link; see [video proof](https://darting.dev/docs/video-proof/).

## Hosted Worker logs

If your deployed app has a Worker backend, its runtime sends authenticated invocation logs back to darting. The **Deployment** tab's **Runtime logs** show requests and scheduled runs, including console output, exceptions, and outbound request statuses; you can filter to errors. This ingest belongs to the hosted Worker, not to a public thread-driving interface. Build output is separate in the deployment's **Build log**. See [hosting](https://darting.dev/docs/hosting/) for the frontend and Worker deployment model.