Open Astrolabe to your tools

Some of your tools call Astrolabe by themselves: GitHub sends a webhook, a pipeline declares a deployment, an AI assistant reads the catalog. They are programs, not people: they never go through a sign-in page.

If a sign-in proxy protects your Astrolabe (Cloudflare Access, oauth2-proxy, your company's single sign-on), it must let these addresses through. This page lists them all, says why each one is called and what protects it, and shows how to open them.

⚙️ Why it matters

A sign-in proxy answers a program the way it answers a person: with its sign-in page. Many proxies send that page with the status 200. The tool reads 200 and believes its call was delivered; Astrolabe never received it. Nothing breaks loudly: the event journal stays empty, the deployment never shows, the assistant never connects.

Opening these addresses opens nothing else. Each one checks its caller itself, with the secret, token or access listed below.

📋 The addresses

Replace astrolabe.acme.example by the address of your Astrolabe.

Webhooks

Each tool sends what just happened to the event journal and the notifications. Without its webhook, Astrolabe reads the tool every few minutes instead.

Method	Address	Called by	What protects it	If it is closed
POST	/api/orion-events/github	GitHub	The webhook secret, in the header X-Hub-Signature-256	Administration › Webhooks says No call received since Astrolabe started. while GitHub shows its deliveries as successful
POST	/api/orion-events/gitlab	GitLab	The webhook secret, in the header X-Gitlab-Token	Same, for GitLab
POST	/api/orion-events/jira	Jira	The webhook secret, in the header X-Hub-Signature	Same, for Jira
POST	/api/orion-events/argocd	Argo CD	The webhook secret, in the header X-Argocd-Token	Same, for Argo CD
POST	/api/orion-events/sonarqube	SonarQube	The webhook secret, in the header X-Sonar-Webhook-HMAC-SHA256	Same, for SonarQube
POST	/api/orion-events/grafana	Grafana	The webhook secret, in the header Authorization	Same, for Grafana
POST	/api/orion-events/azure	Azure DevOps	The webhook secret, in the header X-Azure-DevOps-Token or Authorization	Same, for Azure DevOps

The secrets are set in Administration › Webhooks: Set the webhook secret.

Pipelines

Method	Address	Called by	What protects it	If it is closed
POST	/api/release-manager/pipeline/projects/{project}/environments/{environment}	Your pipeline (GitHub Actions, GitLab CI, Jenkins…), at the end of a deployment	The pipeline token, in the header Authorization: Bearer	The pipeline receives an HTML page or a redirection instead of JSON; the version never shows in Deployments

The token is generated in Administration › Plugins › Deployments: Report deployments from your pipelines.

AI assistants

Your users' assistant (Claude, Cursor…) connects to Astrolabe's MCP server. The user approves it once in the browser; the assistant then calls these addresses by itself.

Method	Address	Called by	What protects it	If it is closed
POST	/api/mcp-actions/v1/astrolabe	The assistant, to read the catalog with the user's rights	The access Astrolabe gave the assistant, in the header Authorization: Bearer	The assistant cannot connect, or says the server does not answer
GET	/.well-known/oauth-protected-resource/api/mcp-actions/v1/astrolabe	The assistant, to learn who gives access to the server	Nothing to protect: a public description, no data	The assistant never offers the approval
GET	/.well-known/oauth-authorization-server/api/auth	The assistant, to find where to ask for its access	Nothing to protect: a public description, no data	The assistant never offers the approval
GET	/api/auth/.well-known/openid-configuration	Some assistants, for the same description	Nothing to protect: a public description, no data	These assistants never offer the approval
POST	/api/auth/v1/token	The assistant, to turn the user's approval into an access, then to renew it	The approval code or the renewal token Astrolabe gave it	The user approves the assistant, then it fails to connect; later, the connection drops when the access expires

The MCP server is off until an administrator turns it on: Turn on the MCP server.

Monitoring

Only if your monitoring runs outside your network.

Method	Address	Called by	What protects it	If it is closed
GET	/.backstage/health/v1/readiness	Your monitoring	Nothing to protect: a status, no data	Your monitoring reads the proxy's answer instead: Astrolabe looks down, or always up

What stays behind your sign-in

Everything else. People open Astrolabe in their browser, sign in to your proxy first, then to Astrolabe: the sign-in page, the approval of an assistant and every screen go through your proxy as usual. Do not open more than the addresses above.

🔧 Let them through

With Cloudflare Access

1. In Cloudflare Zero Trust, open Access › Applications and click Add an application.

2. Choose Self-hosted.

3. Add one destination per line of this table, on the domain of your Astrolabe:

   Path
   api/orion-events
   api/release-manager/pipeline
   api/mcp-actions
   .well-known
   api/auth/.well-known
   api/auth/v1/token

   Add .backstage/health too if your monitoring is outside your network.

4. Add a policy with the action Bypass, and include Everyone.

5. Save the application.

Your application that protects the whole domain stays as it is: Cloudflare applies the most specific path first. This step was not checked on a live instance.

With oauth2-proxy

Give it the addresses to skip, one --skip-auth-route per line:

--skip-auth-route='POST=^/api/orion-events/'
--skip-auth-route='POST=^/api/release-manager/pipeline/'
--skip-auth-route='^/api/mcp-actions/'
--skip-auth-route='GET=^/\.well-known/'
--skip-auth-route='GET=^/api/auth/\.well-known/'
--skip-auth-route='POST=^/api/auth/v1/token$'

Add --skip-auth-route='GET=^/\.backstage/health/' if your monitoring is outside your network. This step was not checked on a live instance.

✅ Check

From a machine outside your network, without signing in to your proxy:

curl -s -X POST https://astrolabe.acme.example/api/orion-events/github

Astrolabe answers itself, in JSON:

{"error":{"name":"AuthenticationError","message":"Missing credentials"}, …}

The call is refused because it has no secret: that is expected, it reached Astrolabe. An HTML page, or a redirection to a sign-in page, means the proxy answered instead: go back to Let them through.

Then make a real call from the tool: push a commit, or click Redeliver on the last delivery of the webhook in GitHub. Administration › Webhooks now says Last call accepted followed by a date.

🆘 Common problems

What you see	What to do
GitHub shows the deliveries as successful (200), and Administration › Webhooks says No call received since Astrolabe started.	Open the last delivery in GitHub (Settings › Webhooks › Recent Deliveries) and read the Response body. A sign-in page (for example Sign in ・ Cloudflare Access) means your proxy answered: let the address through.
The pipeline's call answers with HTML, or follows a redirection	Same cause: let the pipeline address through, in the Pipelines table.
The assistant opens the approval page, you approve, then the assistant says it cannot connect	An address of the AI assistants table is closed in your proxy: open them all.
The curl of Check answers {"error":{"name":"AuthenticationError","message":"Missing credentials"}, …} but Administration › Webhooks says the source signs with another secret	The address is open; the secret differs. See Common problems with webhooks.

Still stuck?

Write to support@forgeit.fr with the address the tool calls and the response body it shows.