> For the complete documentation index, see [llms.txt](https://docs.hivel.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.hivel.ai/hybrid-hivel-agent/2.-getting-started/network-calls-inbound-and-outbound.md).

# 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](/integrations/ai-tools/claude-integrations.md).

`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:**

<table data-header-hidden data-search="false"><thead><tr><th></th><th></th><th></th></tr></thead><tbody><tr><td><strong>Field</strong></td><td><strong>Provider</strong></td><td><strong>Description</strong></td></tr><tr><td>jira.last_synced_at</td><td>Jira</td><td>RFC3339 timestamp of last successful Jira sync. Agent fetches issues updated since last_synced_at - 3h.</td></tr><tr><td>jira.issue_metadata_cursor</td><td>Jira</td><td>Highest Jira issue PK seen. Used for detecting new issues in large instances.</td></tr><tr><td>jira.issue_ids_to_redownload</td><td>Jira</td><td>Issue IDs that failed processing downstream - agent re-fetches these on next run.</td></tr><tr><td>jira.project_ids_to_keys</td><td>Jira</td><td>Map of Jira project numeric ID → project key (e.g. "10001": "ENG").</td></tr><tr><td>github.&#x3C;slug>.last_synced_at</td><td>GitHub</td><td>RFC3339 timestamp - agent fetches commits/PRs updated since this time.</td></tr><tr><td>github.&#x3C;slug>.known_repo_ids</td><td>GitHub</td><td>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.</td></tr><tr><td>gitlab.&#x3C;slug>.last_synced_at</td><td>GitLab</td><td>Same semantics as GitHub.</td></tr><tr><td>bitbucket.&#x3C;slug>.last_synced_at</td><td>Bitbucket</td><td>Same semantics as GitHub.</td></tr><tr><td>azure_devops.&#x3C;slug>.last_synced_at</td><td>Azure DevOps</td><td>Same semantics as GitHub. Note the top-level key is azure_devops, not azure.</td></tr><tr><td>azure_devops.&#x3C;slug>.known_repo_ids</td><td>Azure DevOps</td><td>Repo IDs seen in previous syncs - same new-repo-detection semantics as GitHub.</td></tr></tbody></table>

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](/hybrid-hivel-agent/5.-configuration-reference/claudeotel-settings-claudeotel.md) for details.

**On each of your tools - allowlist the agent VM's IP:**

<table data-header-hidden data-search="false"><thead><tr><th></th><th></th></tr></thead><tbody><tr><td><strong>Tool</strong></td><td><strong>Where to configure</strong></td></tr><tr><td>Jira Server / Data Center</td><td>Network settings or reverse proxy allowlist</td></tr><tr><td>GitHub Enterprise Server</td><td>Management Console → Network → Allowlist</td></tr><tr><td>GitLab self-hosted</td><td>Admin Area → Network → Outbound requests / IP restrictions</td></tr><tr><td>Bitbucket Server</td><td>Firewall / network policy on the host.</td></tr><tr><td>Azure DevOps Server (on-prem/TFS)</td><td>Firewall / network policy on the host.</td></tr><tr><td>Jira Cloud / GitHub.com / GitLab.com / Bitbucket.org / Azure DevOps Services</td><td>No allowlist needed - these are public SaaS</td></tr></tbody></table>

{% columns %}
{% column valign="middle" %} <a href="/hybrid-hivel-agent/2.-getting-started.md" class="button primary" data-icon="backward">Getting Started</a>
{% endcolumn %}

{% column %}

{% endcolumn %}

{% column %} <a href="/hybrid-hivel-agent/2.-getting-started/system-requirements.md" class="button primary" data-icon="forward">System requirements</a>
{% endcolumn %}
{% endcolumns %}