EddytorDocs & API
Authentication

Start a backend-mediated OAuth link flow.

Persists a one-time state + PKCE verifier keyed to the authenticated user, then returns the IdP authorize URL the client should navigate to. The IdP will redirect the browser back to `${server.public_url}/api/v1/auth/providers/:provider/callback` (or the `server.oauth_redirect_base` override) after the user consents. Use this for any client that can open a browser: frontend popup, CLI (via system browser), MCP client (via user's browser), Python SDK.

POST
/v1/auth/providers/{provider}/authorize

Authorization

BearerAuth
AuthorizationBearer <token>

Security scheme for OpenAPI endpoints. Validates both JWT tokens and API keys.

In: header

Path Parameters

provider*string

Value in

  • "azure"
  • "gitHub"
  • "google"

Request Body

application/json

TypeScript Definitions

Use the request body type in TypeScript.

Request body for POST /v1/auth/providers/:provider/authorize.

Response Body

application/json

application/json

application/json

application/json

application/json

application/json

application/json

application/json

application/json

application/json

curl -X POST "https://example.com/v1/auth/providers/azure/authorize" \  -H "Content-Type: application/json" \  -d '{}'
{  "authorizeUrl": "string",  "state": "string"}
Empty
Empty
{  "code": "string",  "message": "string",  "request_id": "string",  "details": [    {      "field": "string",      "message": "string"    }  ]}
{  "code": "string",  "message": "string",  "request_id": "string",  "details": [    {      "field": "string",      "message": "string"    }  ]}
{  "code": "string",  "message": "string",  "request_id": "string",  "details": [    {      "field": "string",      "message": "string"    }  ]}
{  "code": "string",  "message": "string",  "request_id": "string",  "details": [    {      "field": "string",      "message": "string"    }  ]}
{  "code": "string",  "message": "string",  "request_id": "string",  "details": [    {      "field": "string",      "message": "string"    }  ]}
{  "code": "string",  "message": "string",  "request_id": "string",  "details": [    {      "field": "string",      "message": "string"    }  ]}
{  "code": "string",  "message": "string",  "request_id": "string",  "details": [    {      "field": "string",      "message": "string"    }  ]}
{  "code": "string",  "message": "string",  "request_id": "string",  "details": [    {      "field": "string",      "message": "string"    }  ]}
{  "code": "string",  "message": "string",  "request_id": "string",  "details": [    {      "field": "string",      "message": "string"    }  ]}

API Reference

The Eddytor REST API, generated from the OpenAPI spec.

Check which resource planes the caller's provider link is actually consented for.

Azure issues a token for **one resource per consent**, so a link can cover the control plane (browse storage accounts) without covering the data plane (read/write blobs) — the link itself looks fine and only fails later, at container registration. This endpoint answers which is which by *acquiring a token per plane*: the only authoritative signal available to us, since the provider never tells us what a stored grant is consented for. **Not for polling.** Each plane costs a token request to the provider and rotates the stored refresh token. Use `/status` to watch for a link completing; use this once afterwards, or when diagnosing a `provider_reauth_required`. **Required scope:** none beyond authentication — reports on the caller's own link.