# Network requirements

> The hosts Apigami needs to reach and be reached on, what each one is for, and what fails when one is blocked.

Apigami is three parties on three network paths: the **agent or server** that calls the API or the
MCP endpoint, the **browser** where Apigami runs for the user, and the **browser** that signs in to the
dashboard. They do not need the same hosts, and blocking one of them fails in its own way.

If you run an AI agent in a sandbox with an outgoing allow-list — a cloud coding environment, a CI
job, a corporate proxy — this page is the list to hand to whoever maintains it. An agent in a hosted
chat, such as Claude or ChatGPT, needs none of it: the person adds Apigami as a connector, which runs
outside the sandbox ([For AI agents](/docs/ai-agents/#ask-the-person-to-add-the-connector)).

## The hosts

| Host | Who reaches it | What for | What fails without it |
|---|---|---|---|
| `api.eu.apigami.com` | your code, your agent, your MCP client | The REST API, `POST /call`, the MCP endpoint `/mcp`, and the one-shot upload URLs a version deposit hands out | everything: no call, no tool, no upload |
| `auth.eu.apigami.com` | your MCP client | The OAuth authorization server that mints the token `/mcp` accepts | the MCP connection never authenticates, and the client loops on signing in |
| `app.apigami.com` | the user's browser | The dashboard, sign-up and sign-in, the `/connect` page where a user connects to an application and attaches a browser, the OAuth consent screen | nobody can sign up or sign in, and no user can connect to an application |
| `broker.eu.apigami.com` | the user's browser, through Apigami | The connection Apigami holds open in the browser | every browser reads as offline, and every call answers `extension offline` |
| `*.apigami.tech` | the user's browser, and anyone with the address | Your application's own address: Apigami's hosting serves each application at `{slug}.apigami.tech` and its version on staging at `{slug}--staging.apigami.tech`, its pages, its files and every route of your code | your pages stay blank, in the side panel as full page, and the OAuth callbacks registered there never arrive |
| your own hostnames, such as `app.example.com` | the user's browser, and anyone with the address | Production's pages, once a [domain of yours](/docs/app-domain/#your-own-address-a-custom-hostname) is active | production's pages, which open there, stay blank |
| `www.apigami.com` | anyone | This documentation | nothing breaks; you are reading it |

Every host is reached over HTTPS on port 443. Apigami never asks an environment to open an
**incoming** port: the user's browser dials out, and so does your code.

## The MCP endpoint and an upload are two different requests

This one costs the most time, so it is worth saying plainly. `https://api.eu.apigami.com/mcp` and
the `PUT` of a project archive are the same host, and **they are not necessarily the same network
path**. An MCP client may route its connector traffic through its own infrastructure, while the
`curl` your agent runs goes straight out through the sandbox's proxy. So the tools can work
perfectly while the upload is refused, on the same name.

When that happens, nothing arrives: the deposit is simply never filled, and the reservation expires.
The fallback needs no network of its own — `app_version_write` carries the files as arguments of a
tool call, over the MCP connection that is already working. It costs tokens and it cannot carry a
binary, so it is a fallback, not the normal path.

## When the host cannot be allowed

Sometimes nobody is going to change that list today. Then the order is: write the files with
`app_version_write`, which needs no network of its own; and if the project holds images or fonts
that cannot travel as text, build it from an assistant running on your own machine — Claude Code,
Codex, or any coding assistant with a shell and an ordinary network. It connects to the same MCP
endpoint, on the same account, and works on the same application: nothing is lost by changing
where you sit.

## Checking

- `curl -sS -o /dev/null -w '%{http_code}\n' https://api.eu.apigami.com/healthz` — `200` means the
  API is reachable from where you ran it. Run it from **inside** the environment that will upload,
  not from your laptop.
- A `PUT` refused by a proxy usually answers `403` with an HTML body naming the proxy, or times out.
  A refusal from Apigami is always JSON with an `error` field.