Register & Claim

Two paths produce a registered endpoint — direct registration or claiming from the Discovered tab.

Two paths produce a registered endpoint:

Endpoints belong to an organisation — every endpoint identifier (ASTRAE-…) sits under an organisation identifier (ASTRAO-…).

• Dashboard: registering from your organisation works as before. Registering from your personal account puts the endpoint under your organisation. If you don't have one yet, one is created for you, named after you (rename it later). If you belong to several organisations, you're asked to switch to the one it should go under.
• API: use an API key created in your organisation. A personal API key gets 409 ORG_REQUIRED.

1. Direct registration (one call)

POST /api/endpoints
Authorization: Bearer <organisation-api-key>
Content-Type: application/json

{
  "counterpartyType": "api",
  "name": "Invoice API",
  "counterpartyUrl": "https://api.example.com",
  "trustScoreRequirement": 20,
  "pdlss": {
    "purpose": {
      "categories": ["shopping"],
      "allowedActions": ["shopping.search", "shopping.purchase"]
    }
  }
}

# → returns astraeId "ASTRAE-<22-char>"

The optional pdlss block attaches the endpoint's permission boundary in the same call — no separate policy step. It is accepted at registration time only: creating a policy alongside a brand-new endpoint is a consent-free create, but changing a live boundary requires a signed-in session on the endpoint's boundary screen (API keys are rejected for policy mutation).

2. Claim from the Discovered tab

Every authenticated verify-access call with a counterpartyUrl that doesn't match a registered row creates a discovered row owned by the caller (the SDK operator). These appear in the Discovered tab at /endpoints — click Claim to promote them to self_asserted without losing traffic history.

Removing auto-registered endpoints from your active list

Auto-registered endpoints carry an auto-registered badge on the endpoints list. To remove one from your active list, use the standard Deactivate action — the same flow you'd use for endpoints you registered yourself. There's no separate "Dismiss" action: deactivate is the dismiss path for auto-registered rows.

Deactivated rows remain available under the Deactivated tab so audit history stays intact. Use Archive from there if you want the row out of the default views permanently — the underlying audit events are not deleted, just hidden from the working list.

Where orphans live (management vs activity views): auto-registered or discovered orphan endpoints attributed to your account appear in /activity → Endpoints for traffic-attribution and audit purposes. The /endpoints management view filters to endpoints you've explicitly claimed — that's deliberate so the working list stays focused on owned configuration. To deactivate or archive an orphan, find it under /activity → Endpoints, click through to its detail, and use the Deactivate action — same flow as for claimed endpoints.