Network calls - inbound and outbound
IP whitelisting: The agent initiates all connections outbound from the VM it runs on. If your Jira, GitHub Enterprise, GitLab, Bitbucket, or Azure DevOps Server instance is behind a firewall or IP allowlist, you must add the agent VM's IP address (or CIDR range) to the allowlist for each tool. If you're also collecting Claude Code usage, the separate OTel collector component (not hivel-agent) does require inbound access on ports 4317 - see Claude Code Settings.
GET /api/agent/sync-status
The agent calls this on every sync run to determine the incremental window (what was last synced, so it only fetches what's new).
Request:
GET https://api.hivel.ai/api/agent/sync-status
Authorization: Bearer <HIVEL_API_TOKEN>Response - after first sync has completed:
{
"jira": {
"last_synced_at": "2026-05-20T02:00:00Z",
"issue_metadata_cursor": 5563048,
"issue_ids_to_redownload": [],
"project_ids_to_keys": {
"10001": "ENG",
"10002": "INFRA"
}
},
"github": {
"github-main": {
"last_synced_at": "2026-05-20T02:00:00Z",
"known_repo_ids": ["R_abc123", "R_def456"]
}
},
"gitlab": {
"gitlab-main": {
"last_synced_at": "2026-05-20T02:00:00Z"
}
},
"bitbucket": {
"bitbucket-main": {
"last_synced_at": "2026-05-20T02:00:00Z"
}
},
"azure_devops": {
"azure-main": {
"last_synced_at": "2026-05-20T02:00:00Z",
"known_repo_ids": ["a1b2c3d4-...", "e5f6a7b8-..."]
}
}
}Response - very first sync (no prior state):
When last_synced_at is absent for a provider, the agent falls back to earliest_issue_date / earliest_data_date from config and runs a full initial sync.
Key fields:
Field
Provider
Description
jira.last_synced_at
Jira
RFC3339 timestamp of last successful Jira sync. Agent fetches issues updated since last_synced_at - 3h.
jira.issue_metadata_cursor
Jira
Highest Jira issue PK seen. Used for detecting new issues in large instances.
jira.issue_ids_to_redownload
Jira
Issue IDs that failed processing downstream - agent re-fetches these on next run.
jira.project_ids_to_keys
Jira
Map of Jira project numeric ID → project key (e.g. "10001": "ENG").
github.<slug>.last_synced_at
GitHub
RFC3339 timestamp - agent fetches commits/PRs updated since this time.
github.<slug>.known_repo_ids
GitHub
Repo IDs seen in previous syncs. Agent detects new repos by comparing current list against this. New repos get a lookback window instead of full history.
gitlab.<slug>.last_synced_at
GitLab
Same semantics as GitHub.
bitbucket.<slug>.last_synced_at
Bitbucket
Same semantics as GitHub.
azure_devops.<slug>.last_synced_at
Azure DevOps
Same semantics as GitHub. Note the top-level key is azure_devops, not azure.
azure_devops.<slug>.known_repo_ids
Azure DevOps
Repo IDs seen in previous syncs - same new-repo-detection semantics as GitHub.
The <slug> key in github, gitlab, bitbucket, and azure_devops maps matches the instance_slug you set in config.
Firewall / IP allowlist checklist
On the agent VM - allow outbound HTTPS to:
api.hivel.ai and *.s3.amazonaws.com (always required)
Only the tool hosts you are integrating with
On the hivel-agent host - allow inbound (only if the Claude OTel Collector is running there): TCP 4317 (OTLP gRPC) and/or TCP 4318 (OTLP HTTP), whichever your Claude Code clients use, from your developers' machines. See Claude OTel Settings for details.
On each of your tools - allowlist the agent VM's IP:
Tool
Where to configure
Jira Server / Data Center
Network settings or reverse proxy allowlist
GitHub Enterprise Server
Management Console → Network → Allowlist
GitLab self-hosted
Admin Area → Network → Outbound requests / IP restrictions
Bitbucket Server
Firewall / network policy on the host.
Azure DevOps Server (on-prem/TFS)
Firewall / network policy on the host.
Jira Cloud / GitHub.com / GitLab.com / Bitbucket.org / Azure DevOps Services
No allowlist needed - these are public SaaS
Last updated