> ## Documentation Index
> Fetch the complete documentation index at: https://docs.weaveos.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Sazabi

> Import detected issues and Sazabi pull requests, and configure issue attribution.

Connect Sazabi from **Data sources → Sazabi** with an organization-wide secret API key from Sazabi Settings. Weave verifies the key and workspace before saving it. Credentials stay on the server.

Weave imports issues from webhook notifications. Each notification queues its issue, and the next scheduled sync reads that issue from Sazabi with its component and linked Sazabi pull requests. Projects, teams and members refresh on every sync. Issues created before the webhook was configured are not imported, because Sazabi's list endpoints cannot be filtered or resumed by date. Linked pull request dates come from the matching pull request in a connected repository when Sazabi omits them. API imports do not schedule historical BugFinder attribution. Known lifecycle events are partial history.

Map Sazabi projects or components to connected Weave repositories for attribution, and map source teams to Weave teams for report ownership. Component repository mappings override project defaults. Environment labels are explicit reporting labels. These mappings do not create Weave planning projects.

## BugFinder notifications

1. Open **Set up BugFinder webhook** in Weave and copy the public HTTPS endpoint URL.
2. Create the endpoint in [Sazabi Settings → Webhooks](https://app.sazabi.com/settings/webhooks).
3. Save Sazabi's endpoint ID and signing secret in Weave.
4. Route issue triggered, resolved and ignored notifications to that endpoint in Sazabi's project notification settings.
5. Use **Send test** in Sazabi to confirm delivery. Test and unrelated notifications do not create issue or attribution records.

Weave authenticates Sazabi's `2026-09-01` envelope using HMAC-SHA256 over the signed timestamp and exact request bytes. Accepted issue evidence is stored before acknowledgement. Durable source-event and issue identities make retries idempotent; Sazabi does not document a delivery-age limit.

Only triggered notifications create attribution work. The regular clone job processes mapped reports in its existing BugFinder lane, with bounded batches, durable leases and retries. Attribution waits when repository PR search is unavailable. Resolving or ignoring an issue does not start another analysis. Repository mappings are captured once; completed results keep their original repository.

**Issue reports** shows processing status, safe failure reasons, confidence and suspected introducing PRs. These candidates are separate from source-linked PRs; a source link may be a fix or suspected cause. Externally linked PRs are not imported as Sazabi-opened PRs. Access to attribution evidence requires organization-wide report and drilldown permissions. Failed or completed work can be retried for the next regular run.

Disconnecting stops sync and new attribution, clears stored credentials and retains imported history and completed results. Reconnect with a verified key to resume the workspace. Issue reports matched to an introducing PR with medium or high confidence also count toward [Bugs introduced](/metrics/bugs-introduced), and the **Support & operations** report shows Sazabi PR outcomes: proposed, merged, closed and open PRs, merge time, open PR age, and linked issue coverage.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.