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

# HackerOne Integration

> Send bug bounty reports to Odin for HackerOne triage

Connect your HackerOne program so every inbound report lands in Odin, where [HackerOne triage](/platform/bug-bounty-triage) can reproduce it against a live target before your team spends time on it.

<Info>
  HackerOne triage is enabled per organisation. If you don't see it in **Management > Integrations** or in the sidebar, ask Borg to switch it on for your account.
</Info>

HackerOne pushes reports to Odin over a webhook. Report states, comments, and bounty decisions stay in your program.

## What you need

* Admin access to your HackerOne program's settings, so you can add a webhook and mint an API token.
* The program handle — the slug in your program URL, so `acme` in `hackerone.com/acme`.
* An organization API token. In HackerOne, create a group with **Read only** on this program and **Asset inventory viewers**, then add the token to that group. Odin uses the token to list program assets and to fill in a report's asset when the webhook omitted it.

## Connecting

<Steps>
  <Step title="Open Integrations">
    Go to **Management > Integrations** and click **Connect** on the HackerOne card.
  </Step>

  <Step title="Enter handle and API token">
    Type the program handle, the API token identifier (shown once when you created the token — not your email), and the token value. Odin verifies the token can see that program, then imports its assets with auto-triage off.
  </Step>

  <Step title="Copy the URL and secret">
    Odin shows a webhook URL and a signing secret. The secret is shown once and never again, so copy both before you close the dialog.
  </Step>

  <Step title="Add the webhook in HackerOne">
    In your program's **Program settings > Webhooks**, create a webhook with the URL and secret from the previous step. Subscribe it to **Hacker submits report**, **Report is triaged**, and **Report is closed as resolved**.
  </Step>
</Steps>

Reports start arriving as soon as you save the webhook. The first one usually shows up in the [HackerOne inbox](/platform/bug-bounty-triage) within seconds.

<Info>
  Comment and bounty deliveries are ignored. Every comment fires a webhook carrying the full report, so Odin acts only on the three events above and answers everything else with an `ignored` response. An unexpected event type therefore shows up in HackerOne's own delivery log instead of passing silently.
</Info>

## Program assets and auto-triage

Ingesting a report is safe on its own. Triage won't touch a report until that HackerOne asset has a live http(s) URL and/or a bound GitHub repository, and you have authorised testing against it.

Do that in the **Live targets** section of the HackerOne card. Connecting (or **Refresh from HackerOne**) lists every structured-scope asset on the program:

* **HackerOne asset**: the identifier as HackerOne publishes it. Matching on inbound reports is exact.
* **Live target URL**: where triage should send traffic. URL and DOMAIN assets are pre-filled when we can derive `https://…`. Optional if you bind a GitHub repo instead.
* **Scope hosts**: the hosts triage is allowed to reach, comma-separated. Wildcards work: `api.example.com, *.example.com`.
* **Auto-triage new reports**: off by default. Switching it on is consent to triage every new report on that asset. Needs a live URL or a GitHub repo.
* **GitHub repo**: pick a repository already connected in Integrations. Alone that is whitebox; with a live URL it is graybox.

Click **Save targets** when you're done. An asset with neither a live URL nor a GitHub repo stays untriageable, and the report page tells you which asset string to arm.

## Auto-triage

With **Auto-triage new reports** on for an asset, a new report against that asset queues a triage run the moment it arrives. Nothing else triggers it: a triaged or resolved event updates the report in your inbox but never starts a run, and an asset without the switch waits for someone to press **Triage now**.

A `report_created` webhook often omits structured scope. When that happens, Odin re-reads the report with your API token so the asset can still match.

<Warning>
  Auto-triage sends live traffic at the mapped target without anyone reviewing the report first, and each run [consumes credits](/platform/billing). Turn it on for an asset only once you're happy for every new report on it to be reproduced automatically.
</Warning>

Odin caps how many auto-triage runs an organisation can have in flight at once. During a burst of submissions, a report that arrives over the cap is still ingested but doesn't start a run, so it sits in the inbox as **Untriaged** until someone presses **Triage now**.

## Rotating the signing secret

Every delivery is signed, and Odin rejects one whose signature doesn't match. Because the secret is only ever shown when it's created, rotation is the only way back from a lost secret.

Click **Generate new secret** on the HackerOne card. The new secret appears once; paste it into your HackerOne webhook straight away. Deliveries signed with the old secret are rejected from the moment you rotate, so any report submitted in the gap won't reach Odin.

## Notes

* The connection covers one program handle. Reports from another program aren't recognised.
* Removing the connection stops ingest. Delete the webhook in HackerOne as well, otherwise your program keeps sending deliveries that are no longer accepted.
* Findings from HackerOne triage are advisory.