Skip to content
Resplendent DataResplendent Data Docs

Huntress Integration

This integration pulls Huntress REST API v1 data into Resplendent Data for MDR reporting and dashboards.

The integration never creates, updates, or deletes records in Huntress. Write APIs such as agent isolation, incident resolution, and remediation approval are not used.

Before you begin

Section titled “Before you begin”

You need:

  1. A Huntress account with permission to create a User API key
  2. The API Key and API Secret from the Huntress portal (the secret is shown once)

Use a dedicated API user when possible. Regenerating keys invalidates previous keys.

Reseller-shaped credentials are detected with GET /v1/actor. Typical MSP keys use the top-level list endpoints (/v1/agents, /v1/organizations, and so on). Account-scoped lists under /v1/accounts/{account_id}/… are used only when the actor response is reseller-shaped without a usable account.

What you can sync

Section titled “What you can sync”
Dataset Sync behavior Notes
Account Snapshot every 1440 minutes by default Singleton GET /v1/account; one-row list, drained in a single job
Organizations Rolling snapshot; default 5-minute ticks, 6-hour scan Inventory; page_token stored on the rolling cursor. Unseen orgs drop after a complete cycle
Agents Rolling snapshot; default 1-minute ticks, 60-minute scan Fastest rolling Dataset. Inventory; persist organization_id. Hard deletes prune at cycle end
Identities Rolling snapshot; default 5-minute ticks, 6-hour scan Nested account and organization IDs are lifted onto the row
Incident Reports Incremental; first batch then cursor history updated_at watermark; page_token stored on the crawler; nightly resync recovers deletes
Escalations Incremental; first batch then cursor history Same cursor + updated_at pattern; organization_id and account_id are lifted from nested objects
Signals Incremental; first batch then cursor history Uses updated_at, not investigated_at. investigated_at_min is when SOC investigated, not a last-updated filter

Account is a tiny snapshot and replaces the warehouse with the current singleton. Organizations, Agents, and Identities are rolling snapshots: initial_pull writes one API page, then scheduled ticks continue through Huntress pagination.next_page_token in rolling_sync_state until the list is exhausted. That is the Datto RMM Devices job contract, with Huntress opaque page_token paging instead of Datto page numbers. Incremental Datasets still write one configured batch on initial sync or resync, then continue through get_old_rows. last_resync_timestamp does not change fetch size.

Huntress list endpoints cap limit at 500. An incremental batch of 1000 rows spans two API pages in one job. Rolling jobs fetch a bounded number of those pages per tick so a full refresh can finish across a 60-minute Agents window or a six-hour Organizations / Identities window. In Dataset Options, use Full Scan Duration and Sync Frequency to spread the scan. Signals expose investigated_at_min / investigated_at_max, but those filter investigation time rather than row change time, so incremental updates sort by updated_at.

Hard deletes on incremental Datasets are recovered by nightly resync (wipe, then the first configured batch, then history recrawl). Rolling snapshots drop rows that left Huntress after a complete successful cycle. The Account snapshot replace already drops a missing account.

SAT / Curricula (mycurricula.com) and POST /v1/siem/query are out of scope.

Setup instructions

Section titled “Setup instructions”

Step 1: Generate API keys in Huntress

Section titled “Step 1: Generate API keys in Huntress”
  1. Sign in to the Huntress portal
  2. Open user settings and create a User API key
  3. Copy the API Key
  4. Copy the API Secret immediately; Huntress shows it only once

Step 2: Connect in Resplendent Data

Section titled “Step 2: Connect in Resplendent Data ”
  1. Go to Settings → Integrations
  2. Find Huntress and click Connect
  3. Paste the API Key and API Secret
  4. Click Save & Test
  5. After a successful test, click Sync Dataset and choose the Datasets to sync

Limits and behavior

Section titled “Limits and behavior”
  • Huntress allows 60 requests per minute per API account (sliding window). HTTP 429 responses are retried with backoff.
  • Paginated endpoints accept limit from 1 to 500. This is an internal API page size, not the Dataset batch size.
  • Incremental history uses opaque page_token values, not page numbers.
  • Rolling snapshots also use page_token, persisted on the Dataset rolling cursor rather than the legacy crawler.
  • Child rows always persist Huntress id as the primary key and keep organization_id / account_id when Huntress provides them.

Troubleshooting

Section titled “Troubleshooting”
Symptom Likely cause What to try
Invalid credentials Wrong API Key/Secret or revoked keys Generate a new User API key and reconnect
Access denied User cannot read the requested Huntress resources Confirm the API user can view organizations, agents, and incidents
Throttling / temporary failures Account-wide 60 requests/minute limit Wait and retry; reduce concurrent Huntress API consumers
Incomplete history after save Incremental Datasets recrawl one batch per minute Wait for get_old_rows to finish, or raise the Dataset history setting
Missing deleted agents Rolling cycle has not finished since the uninstall Wait for the Agents full scan to complete, or resync the Dataset
Section titled “Related”