> ## Documentation Index > Fetch the complete documentation index at: https://docs.phosra.com/llms.txt > Use this file to discover all available pages before exploring further. # Get provider connect config > Returns the OAuth endpoints `@phosra/link` uses to run the connect ceremony against a provider. This is the **Phosra product layer** of a two-layer resolution — it answers *how* to reach a provider. Whether you *may* connect is decided first by the OCSS Trust List (`/.well-known/ocss/trust-list`, root-verified): the SDK's resolver requires the DID to be an `active`, unexpired entry before this endpoint is ever fetched, and fails closed otherwise. Connect configs are deliberately **not** part of the signed OCSS document — the standard stays vendor-neutral (trust, keys, accreditation); connection mechanics are Phosra's concern as the OCSS implementor. Responds `404` (without distinguishing the cases) when the DID is unknown, revoked, or accredited but has no connect config yet. ## Two layers, resolved in order Connecting a platform to a provider is a **two-layer resolution**, and the layers are deliberately not the same trust surface: 1. **The OCSS Trust List decides *whether* you may connect.** The SDK resolver fetches the root-verified `/.well-known/ocss/trust-list` and requires the target DID to be an `active`, unexpired entry. Absent, suspended, revoked, or expired — the resolver **fails closed** and this endpoint is never called. 2. **This endpoint (`GET /providers/{did}/connect`) says *how* to reach it.** It returns the OAuth `authorize_url` / `token_url` / `profiles_url` / `scopes` a client uses to run the connect ceremony. It is a **Phosra product-layer** lookup, deliberately **not** part of the signed OCSS document — the standard stays vendor-neutral (trust, keys, accreditation); connection mechanics are Phosra's concern as the OCSS implementor. `404` is returned (without distinguishing the cases) for an unknown DID, a revoked DID, or an accredited DID that has no connect config registered yet — no existence leak. ## Registering your connect config There is no self-serve write path for this endpoint yet. To get your platform's connect config published: **Interim (today):** email [developers@phosra.com](mailto:developers@phosra.com) with the four fields: * `authorize_url` — your OAuth 2.0 authorization endpoint (PKCE S256) * `token_url` — your OAuth 2.0 token endpoint * `profiles_url` — your child-profile listing endpoint (bearer access token; the token is discarded after the profile fetch) * `scopes` — the OAuth scopes the connect ceremony should request (e.g. `child_profiles.read`) Phosra publishes the config to the connect registry once your DID is on the Trust List. **Roadmapped:** a self-serve, RFC-9421-signed `PUT` on this same path, so an accredited platform can register and rotate its own connect config without an email round-trip. Not yet built — no such endpoint exists today. ## OpenAPI ````yaml GET /providers/{did}/connect openapi: 3.1.0 info: title: Phosra API description: Universal Parental Controls API - Define once, push everywhere version: 1.0.0 contact: name: Phosra servers: - url: https://prodapi.phosra.com/api/v1 description: Production - url: https://phosra-api-sandbox-production.up.railway.app/api/v1 description: >- Hosted sandbox — the one canonical, stable, partner-facing testing endpoint (seeded demo family + phosra_test_ keys). Same base the CLI uses. - url: http://localhost:8080/api/v1 description: Local development security: - BearerAuth: [] paths: /providers/{did}/connect: parameters: - name: did in: path required: true description: >- The provider's OCSS DID, e.g. `did:ocss:loopline`. Colons are path-safe (RFC 3986) — send them literally, do not percent-encode. schema: type: string pattern: ^did:ocss:[a-z0-9-]+$ get: tags: - Providers summary: Get provider connect config description: >- Returns the OAuth endpoints `@phosra/link` uses to run the connect ceremony against a provider. This is the **Phosra product layer** of a two-layer resolution — it answers *how* to reach a provider. Whether you *may* connect is decided first by the OCSS Trust List (`/.well-known/ocss/trust-list`, root-verified): the SDK's resolver requires the DID to be an `active`, unexpired entry before this endpoint is ever fetched, and fails closed otherwise. Connect configs are deliberately **not** part of the signed OCSS document — the standard stays vendor-neutral (trust, keys, accreditation); connection mechanics are Phosra's concern as the OCSS implementor. Responds `404` (without distinguishing the cases) when the DID is unknown, revoked, or accredited but has no connect config yet. responses: '200': description: The provider's OAuth connect config content: application/json: schema: $ref: '#/components/schemas/ProviderConnectConfig' '400': description: The path segment is not a `did:ocss:` DID '404': description: Unknown, revoked, or not-yet-configured provider (no existence leak) security: [] components: schemas: ProviderConnectConfig: type: object required: - authorize_url - token_url - profiles_url properties: authorize_url: type: string format: uri description: The provider's OAuth 2.0 authorization endpoint (PKCE S256). token_url: type: string format: uri description: The provider's OAuth 2.0 token endpoint. profiles_url: type: string format: uri description: >- The provider's child-profile listing endpoint (bearer access token; the token is discarded after the profile fetch). scopes: type: array items: type: string description: >- OAuth scopes the connect ceremony requests, e.g. `child_profiles.read`. securitySchemes: BearerAuth: type: http scheme: bearer bearerFormat: JWT ````