# Vidreno auth.md

This file tells AI agents and other automated clients how accounts, credentials and machine access work on Vidreno, following the auth.md discovery convention. Vidreno is a platform for filmmakers and video creators: filmmakers publish films on their own pages (Films: free to watch, or sold on demand as a purchase or a rental, with crew credits and filmmaker profiles), and creators host videos, get a shareable link and an embed code, and stream them worldwide on their own sites and apps (Host & Embed). Vidreno runs on two hostnames: https://vidreno.com, which serves the marketing site, the application (registration, sign-in, dashboard and embed player), the OAuth authorization server and the MCP server, and the help center at https://vidreno.com/tutorials. Product facts live in https://vidreno.com/llms.txt; this file covers registration, credentials and discovery.

Short version: humans create accounts and sign in through the browser. Agents act inside an account through the Vidreno MCP server at https://vidreno.com/mcp, authorised with OAuth 2.1 by the account holder (sign-in plus a consent screen). There are no API keys, no personal access tokens and no REST API for agents; the MCP server is the only machine entry point, and it covers the creator's own films and hosted videos only.

## Who this is for

AI agents and automated clients acting on behalf of a human creator or business that wants to host, embed or sell video on Vidreno. If you support MCP with OAuth (ChatGPT, Claude, Cursor, MCP Inspector and similar clients), you can connect the person's Vidreno account and manage their films and hosted videos for them. Otherwise your role is to point them to the right pages and help with public material such as embed codes. You can never create an account or obtain credentials without the human completing the sign-in and consent steps in a browser.

## Registration

The only way to get a Vidreno account is the interactive registration form at https://vidreno.com/register. The human user enters a username, an email address and a password, submits the form and then opens the confirmation link Vidreno e-mails to that address (valid for 60 minutes); the account is created and signed in at that moment. The form answers the same way whether or not the address already has an account, so it cannot be used to check whether someone is registered.

Hand the person that link and let them complete the form themselves; do not fill in or submit it for them. The help-center article [Creating your account](https://vidreno.com/tutorials/creating-your-account) describes the form and what happens next. During an MCP connect flow a visitor without an account can tap "create account" on the sign-in page, register, and is returned to the consent screen afterwards.

## Supported registration methods

- Interactive web form at https://vidreno.com/register, completed by the human user. This is the only supported method for user accounts.
- OAuth clients (MCP clients) register themselves with dynamic client registration at https://vidreno.com/oauth/register (see OAuth discovery below). That registers software, not a person: every token it later obtains is tied to a human who signed in and approved the connection.
- There is no `/agent/auth` endpoint, no other machine provisioning endpoint and no API keys on vidreno.com. None of the agent-only registration flows are supported: no ID-JAG identity assertions, no verified-email assertions and no anonymous credentials.

## Credentials and how to use them

- Sign-in is at https://vidreno.com/login with the account's email address and password. A successful sign-in sets a secure session cookie in the user's browser. That cookie belongs to the user's browser session, not to an agent, and must never be reused outside it. See [Signing in to your account](https://vidreno.com/tutorials/signing-in-to-your-account).
- Agents use OAuth 2.1 bearer tokens issued by https://vidreno.com for the MCP server at https://vidreno.com/mcp. Tokens are obtained with the authorization-code flow with PKCE (S256), are scoped (`films:read`, `films:write` for films; `videos:read`, `videos:write` for hosted videos; `earn:read` for read-only earnings, film sales and payouts), expire after one hour, are refreshed with rotating refresh tokens and can be revoked at https://vidreno.com/oauth/revoke or by disconnecting the app in the client. Send them as `Authorization: Bearer <token>` to https://vidreno.com/mcp only; they are bound to that resource and are not accepted anywhere else.
- Agents must not collect, store or replay a user's password. The sign-in step of the OAuth flow happens in the user's own browser.
- There are no API keys, personal access tokens or other long-lived secrets to put in an `Authorization` header.
- There is no self-serve password reset. A user who loses access contacts support (see Contact below) to be restored.

## OAuth discovery

Vidreno runs an OAuth 2.1 authorization server on https://vidreno.com for the MCP server. It publishes the standard metadata documents:

- Protected Resource Metadata (RFC 9728): https://vidreno.com/.well-known/oauth-protected-resource/mcp (resource `https://vidreno.com/mcp`, authorization server `https://vidreno.com`).
- Authorization Server Metadata (RFC 8414): https://vidreno.com/.well-known/oauth-authorization-server (issuer `https://vidreno.com`).
- Endpoints: authorize https://vidreno.com/oauth/authorize, token https://vidreno.com/oauth/token, dynamic client registration https://vidreno.com/oauth/register (RFC 7591; `none`, `client_secret_basic` and `client_secret_post`; registrations do not expire), revocation https://vidreno.com/oauth/revoke (RFC 7009).
- Requirements: `response_type=code`, PKCE with `code_challenge_method=S256` (mandatory), exact match on a registered HTTPS or loopback redirect URI, `resource=https://vidreno.com/mcp` (RFC 8707; the only accepted value), any of the scopes `films:read`, `films:write`, `videos:read`, `videos:write`, `earn:read` (a request above what the client registered for is narrowed to the registered set). Authorization responses carry `iss` (RFC 9207).
- Discovery is public: a request to https://vidreno.com/mcp with no `Authorization` header may `initialize`, `ping` and `tools/list` (the full catalogue, the same one described below), so directories and clients can inspect the server before anyone signs in. Any tool call without a token — and any request with an invalid or expired token, whatever the method — answers 401 with a `WWW-Authenticate: Bearer resource_metadata="..."` challenge pointing at the resource metadata, which is how MCP clients start the flow automatically. Opening https://vidreno.com/mcp in a browser shows a short explanation page instead.
- There is no OpenID provider and no `/.well-known/openid-configuration`; the OAuth server issues access tokens for the MCP server only and does not serve as a general sign-in for other sites.

## The MCP server

- Availability: live for Claude, Cursor and any OAuth-capable MCP client; the ChatGPT app is coming soon.
- Endpoint: https://vidreno.com/mcp (Model Context Protocol, Streamable HTTP transport; bearer token required for every tool call, discovery is public). Add it as a connector in ChatGPT developer mode or any MCP client with OAuth support; the client discovers the OAuth server through the metadata above, the user signs in and approves the connection on a consent screen, and the client can then show which account is connected.
- What it can do, for the connected creator's own account only. Films (`films:*`): create a new draft film from a title (the agent gets its id, editor link and publish checklist back), list and search their films, read one film's status, release mode (free to watch or buy/rent), prices, play count, credits and public page link, change its metadata, release mode and prices, publish or unpublish it (publishing is refused with the editor's checklist message until title, poster, a ready main film and, only for buy/rent, a price are in place; the poster is added in the film editor, whose link the refusal carries, not through the server), add, remove and reorder crew credits (linked to a filmmaker by username or invited by e-mail, with the app's limits), and upload a main film or trailer through the same browser hand-off link as hosted videos. Films are never embeddable: no tool returns an embed code for a film. Hosted videos (`videos:*`): list and search videos, read a video's details, build an embed code with player options (autoplay, muted, loop, controls, corner radius, fullscreen, responsive or fixed size), rename a video or change its description, visibility, player colour and category, delete a video (after explicit confirmation), read account and analytics summaries, and start a new upload. Uploading hands the user a one-hour, single-use link to https://vidreno.com/upload/<id> where they pick the file in their browser; the agent then checks the upload status and gets the embed code (for a film file, it checks the film instead). `get_account` also reports which product the account is set up for (Films, or Host & Embed; a preference, not a restriction on the tools), the film counts and the public filmmaker-profile link. Earnings (`earn:read`, read-only): `get_earnings` returns the balance (available, maturing, paid out, in flight), lifetime and current-month earnings split into film sales and ads, the payout minimum and hold period, the payout method in masked form, whether ad earnings are live for the account, a per-film breakdown (sales, refunds, gross, net) and the latest payouts; `list_payouts` pages the payout history (amount, status, method, masked destination, dates, failure reason); `list_film_sales` pages the seller's film orders (film, purchase or rental, price, platform cut, processor fee and whether it is still estimated, paid or refunded, net credited, dates) with optional film and status filters. Amounts are cents plus a display string. No buyer identity, no unmasked payout details, no numeric ids.
- What it cannot do: files cannot be sent through the MCP connection; it cannot request a payout, change the payout method or see buyer identities, full PayPal addresses or bank account numbers; advertising, billing, profile editing and admin functions are not exposed; there is no public (unauthenticated) film browsing; it never returns data about other accounts. Only creator accounts can connect: advertiser and viewer accounts are told so on the consent screen.
- For the human: the help-center article [Manage your videos from ChatGPT](https://vidreno.com/tutorials/manage-your-videos-from-chatgpt) explains how to add the connector, what the sign-in and consent screens mean, what the assistant can and cannot do, how the upload link works and how to disconnect. Point people there when they ask how to connect you.

## What needs no credentials

The following are public and can be read without an account:

- The marketing pages on https://vidreno.com, including https://vidreno.com/llms.txt and https://vidreno.com/sitemap.xml.
- The help center at https://vidreno.com/tutorials.
- Public embed player URLs of the form https://vidreno.com/embed/<video-id>, which are what the embed code loads in an iframe.
- oEmbed metadata for public video links, advertised through the standard oEmbed link tag on each video page (see [oEmbed support](https://vidreno.com/tutorials/oembed-support-for-notion-and-wordpress)).
- The OAuth metadata documents and https://vidreno.com/oauth/register listed above.

Uploading and managing films and videos happens in the app for a signed-in human, or through the MCP server for an agent the human has connected.

## Contact

- Contact form: https://vidreno.com/contact (no public support email address; signed-in users can open a ticket from the ticket center at https://vidreno.com/support)

Last updated: 5 October 2026. This file will be updated if Vidreno adds further API or OAuth capabilities.
