Integrations

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 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 covers access to the repo, and 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 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, 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.

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 for the frontend and Worker deployment model.