Network requirements

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).

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 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.