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

# Connecting Huntress to Neo

> Generate a Huntress API key pair, save it in Neo, and decide what each agent can do

You connect Huntress once at the MSP level, then turn it on per agent. Setup takes a few minutes.

<Info>
  Huntress uses one API key pair (a public key and a secret key) per Huntress account. There is no per-customer URL — organizations are scoped inside the API, so one key pair covers every customer in the account.
</Info>

## 1. Generate an API key pair in Huntress

<Steps>
  <Step title="Open API Credentials">
    Sign in at `<your-subdomain>.huntress.io` as a user with **Admin** privileges, open the hamburger menu in the top-right corner, and choose **API Credentials**. If you don't see the option, you're signed in as a non-Admin user — an Admin on your account can create the key, or grant you the role.
  </Step>

  <Step title="Decide which key you need">
    Huntress offers an account key and user-based keys. **The default account API key is read-only.** If you want Neo to isolate hosts, approve remediations, resolve incidents, or manage organizations and users, generate a **user-based key** whose Huntress user holds those portal permissions.

    <Tip>
      Create the user-based key against a dedicated Huntress user (for example "Neo Agent") rather than a person's login, so the audit trail in Huntress names the automation and the key survives staff changes.
    </Tip>
  </Step>

  <Step title="Generate and copy both values">
    Click **Setup**, then **Generate**. Huntress shows the **API Secret Key only once** — copy both the public key and the secret before leaving the page. If you lose the secret, regenerate the pair; you cannot retrieve it later.
  </Step>
</Steps>

## 2. Add the keys in Neo

<Steps>
  <Step title="Open Integrations">
    In the Neo Dashboard, open **Integrations** and find the **Huntress** card under **Security**.
  </Step>

  <Step title="Save both values">
    Paste the API Key and the API Secret, then click **Save**.

    <Check>
      Neo tests the pair by reading the Huntress account the credentials belong to. If either value is wrong, the save fails so you can fix it before moving on.
    </Check>
  </Step>
</Steps>

Neo stores the secret encrypted and only ever shows it masked afterwards. The public key stays visible so you can confirm which key pair is connected.

## 3. Turn Huntress on per agent

Each agent decides whether it uses Huntress and which areas it can touch. Open the agent, go to the **Integrations** section, and configure the Huntress block.

### Pick an access profile

<CardGroup cols={2}>
  <Card title="Read Only" icon="magnifying-glass">
    Every area read only. The agent can investigate any alert, host, or report but never changes anything. Best for triage, reporting, and QBR agents.
  </Card>

  <Card title="Helpdesk" icon="headset">
    Incidents at read/write — still behind technician approval on every write — and read-only everywhere else. Enough to work an alert to resolution without touching hosts, access rules, or users.
  </Card>

  <Card title="IT Admin" icon="user-shield">
    Every writable area at read/write, with technician approval required on all writes. The cautious rollout tier.
  </Card>

  <Card title="Full Automation" icon="bolt">
    Access rules and organization changes run autonomously. Host isolation, remediation approval, incident resolution, and portal access changes still require technician approval — that cannot be turned off.
  </Card>
</CardGroup>

### Or set each area yourself

| Permission group          | Access levels                     |
| ------------------------- | --------------------------------- |
| **Incidents**             | Disabled / Read Only / Read-Write |
| **Agents**                | Disabled / Read Only / Read-Write |
| **Unwanted Access Rules** | Disabled / Read Only / Read-Write |
| **Organizations**         | Disabled / Read Only / Read-Write |
| **Users**                 | Disabled / Read Only / Read-Write |
| **Detections**            | Disabled / Read Only              |
| **Reporting & Billing**   | Disabled / Read Only              |

Detections and Reporting & Billing are read-only because the Huntress API has no write endpoint for them.

<Note>
  Changing a customer's Huntress subscription is deliberately not exposed to agents, even though the Huntress API supports it. Reporting & Billing is read-only for reconciliation and QBRs, not for buying.
</Note>

## Troubleshooting

| What you see                                  | What it means                                                                                                                                                                                                     |
| --------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Save fails immediately                        | One of the two values is wrong, or API access is not enabled for your Huntress account. Regenerate the pair and re-enter both.                                                                                    |
| Reads work but a write fails with "not found" | The connected key lacks that portal permission. Huntress returns the same "not found" response for "doesn't exist" and "you can't touch it" — the default account key is read-only, so generate a user-based key. |
| Calls start failing under load                | Huntress rate limits each account to 60 requests per minute. Neo backs off, but an agent doing a very wide sweep can hit it — narrow the query, or scope it to one organization.                                  |