> ## Documentation Index > Fetch the complete documentation index at: https://docs.useselo.xyz/llms.txt > Use this file to discover all available pages before exploring further. # Authorization > Why Selo tests only routes their owner has authorized, how the well-known file proof works, and what happens when an authorization lapses. Selo sends real requests and real payments. A release test pays your endpoint, then replays the identical signed payment against it. Pointed at someone else's API, that would be unwanted traffic with money attached. So Selo tests a route only while a verified, unexpired authorization covers its exact origin, path and method. Consent is never inferred. ## Scope An authorization covers one route and one method. Selo compares all three parts exactly. | Part | What it is | Example | | - | - | - | | Origin | `https://` plus the hostname. Only the default port is allowed | `https://api.example.com` | | Route path | The URL path, matched exactly. The query string and fragment are not part of the scope, and `/v1/orders` and `/v1/orders/` are different routes | `/v1/orders` | | Method | `GET` or `POST` | `POST` | To test `GET` and `POST` on the same path, or two paths on the same origin, create one authorization for each. The target URL must also pass Selo's address rules: HTTPS only, no user name or password in the URL, no explicit port, a hostname rather than an IP address, at least two labels, and not a local name such as `.local` or `.internal`. See the [security model](https://docs.useselo.xyz/concepts/security.md#target-url-rules). ## Two ways to authorize **Well-known file** The standard method, available to anyone through the API or the CLI. You prove control of the origin by serving a token Selo gave you. The authorization's `type` is `well_known_file`. **Manual owner consent** For an endpoint whose owner cannot serve a file, the Selo operator can record the owner's consent explicitly. The authorization's `type` is `manual_owner_consent`. There is no API route for it, and Selo never creates one on its own. ## The well-known file method **1. Create the authorization** Send the target URL, the method, a project name (1 to 80 characters) and a contact (3 to 200 characters). ```bash Terminal theme={null} curl -X POST https://api.useselo.xyz/v1/authorizations \ -H "content-type: application/json" \ -d '{"targetUrl":"https://api.example.com/v1/orders","method":"POST","project":"orders-api","contact":"you@example.com"}' ``` Selo answers `201` with a pending authorization and the line to publish: ```json 201 Created theme={null} { "authorizationId": "auth_…", "status": "PENDING", "origin": "https://api.example.com", "routePath": "/v1/orders", "method": "POST", "verificationUrl": "https://api.example.com/.well-known/selo-verification.txt", "expectedContent": "selo-verification=" } ``` The token is 32 random bytes, encoded as 43 base64url characters. This response is the only time Selo returns it. **2. Publish the line** Serve the `expectedContent` line at `verificationUrl`, on the same origin as the route. The file may hold other lines, so one file can carry the tokens for several authorizations on the same origin. ```text .well-known/selo-verification.txt theme={null} selo-verification= ``` **3. Verify** Ask Selo to read the file: ```bash Terminal theme={null} curl -X POST https://api.useselo.xyz/v1/authorizations/auth_…/verify ``` ```json 200 OK theme={null} { "authorizationId": "auth_…", "status": "VERIFIED", "origin": "https://api.example.com", "routePath": "/v1/orders", "method": "POST", "type": "well_known_file", "verifiedAt": "