generated: '2026-07-26' method: searched docs: https://github.com/RESOStandards/transport/blob/main/proposals/web-api-core.md source: - https://github.com/RESOStandards/transport/blob/main/proposals/web-api-core.md - https://github.com/RESOStandards/reso-tools/blob/main/reso-mcp-server/doc/GUIDE.md - https://github.com/RESOStandards/reso-tools/blob/main/reso-certification/README.md note: >- Two authentication stories that must be held apart. (1) The auth model RESO MANDATES for every RESO-certified Web API server - OAuth2 Bearer tokens or OAuth2 Client Credentials over TLS 1.2+, with credentials issued by the individual MLS, never by RESO. (2) The auth on the one endpoint RESO itself operates - the RESO Cloud MCP Server at services.reso.org/mcp, which gates on a static bearer API key issued by RESO on request. Derived from OpenAPI securitySchemes was not possible: RESO publishes no OpenAPI, so this profile is transcribed from the ratified specification text. summary: types: [oauth2, http] api_key_in: [header] oauth2_flows: [clientCredentials] transport_security: TLS 1.2 or above (mandatory) openid_connect: >- Removed. "The Open ID Connect layer was previously supported by the RESO Web API. As of Web API 1.0.2, RESO only supports Bearer tokens and Client Credentials during Certification." scopes_published: false schemes: - name: OAuth2 Bearer Token type: http scheme: bearer applies_to: RESO-certified Web API servers (any MLS or data provider) required: true spec_text: >- "Providers MUST use either OAuth2 Bearer tokens or Client Credentials for authentication (RCP-026)." spec: Web API Core 2.0.0/2.1.0 (RCP-37), section on Authentication; RCP-WEBAPI-026 issuer: The individual MLS or its software provider. RESO issues no Web API credentials. - name: OAuth2 Client Credentials type: oauth2 flow: clientCredentials applies_to: RESO-certified Web API servers (any MLS or data provider) required: true token_url: Provider-specific - each MLS publishes its own token endpoint. RESO defines no central one. parameters: [client_id, client_secret] spec_text: >- "A type of authorization grant that uses a client_id and client_secret ... in order to provide a Bearer Token upon request. This method is more resilient against man-in-the-middle attacks than Bearer Tokens since there is an additional token request step involved, and tokens may be expired and refreshed programmatically." spec: Web API Core 2.0.0/2.1.0 (RCP-37) - name: RESO Cloud MCP API key type: apiKey in: header parameter: Authorization format: 'Bearer ' applies_to: https://services.reso.org/mcp required: true issuer: RESO how_to_obtain: >- Email dev@reso.org with name, organization and intended use case (development, testing, demo, integration). Beta programme; keys available to RESO members and conference attendees. self_serve: false probe: {url: 'https://services.reso.org/mcp', anonymous_status: 401, date: '2026-07-26'} client_support: reso_client_sdk: package: '@reso-standards/reso-client' supports: [bearer token, oauth2 client credentials] reso_cert_cli: package: '@reso-standards/reso-certification' resolution_order: - 'CLI flags: --auth-token, or --client-id / --client-secret / --token-url' - 'Config file: --config path/to/config.json (per-entry auth)' - '.env file in the current directory' - 'Environment variables: RESO_AUTH_TOKEN, or RESO_CLIENT_ID / RESO_CLIENT_SECRET / RESO_TOKEN_URI' web_api_commander: language: java supports: [bearer token, oauth2 client credentials] error_semantics: '403': Returned when the selected authentication mechanism is not successful (Web API Core section 2.6.1). access_reality: >- Authentication is standardised; access is not. A RESO-certified endpoint proves conformance to this OAuth2 contract and proves nothing about reachability - credentials are issued only after a data licence is signed with the individual MLS that runs the endpoint.