generated: '2026-09-07'
method: searched
source: >-
  openapi/_original/cvent-hospitality-cloud-rest-apis-openapi.json (harvested from
  https://developers.cvent.com/documentation) + live /.well-known probes + https://trust.cvent.com/
note: >-
  Every entry below is evidenced by a location in a contract we fetched or a document we probed, not by
  a marketing claim. Where a standard is genuinely absent — RFC 9457 problem details, OpenID Connect on
  the API platform, RFC 9116 security.txt — it is recorded as conforms:false rather than omitted, because
  an honest negative is the useful measurement.
conformance:
  - id: oauth2
    name: OAuth 2.0 (RFC 6749)
    conforms: true
    evidence: >-
      components.securitySchemes declares OAuth2.clientCredentials and OAuth2.authorizationCode with
      authorizationUrl https://api-platform.cvent.com/ea/oauth2/authorize and tokenUrl
      https://api-platform.cvent.com/ea/oauth2/token, carrying 238 named scopes —
      openapi/cvent-hospitality-cloud-authentication-openapi.yml
  - id: oauth2-pkce
    name: OAuth 2.0 PKCE (RFC 7636)
    conforms: true
    scope: MCP surface only
    evidence: >-
      code_challenge_methods_supported ["S256"] in
      well-known/cvent-hospitality-cloud-mcp-oauth-authorization-server.json
      (https://mcp.cvent.com/.well-known/oauth-authorization-server, HTTP 200)
  - id: rfc8414
    name: OAuth 2.0 Authorization Server Metadata (RFC 8414)
    conforms: true
    scope: MCP surface only
    evidence: >-
      https://mcp.cvent.com/.well-known/oauth-authorization-server returns HTTP 200 with issuer,
      authorization_endpoint, token_endpoint, grant_types_supported and
      token_endpoint_auth_methods_supported
  - id: rfc9728
    name: OAuth 2.0 Protected Resource Metadata (RFC 9728)
    conforms: true
    scope: MCP surface only
    evidence: >-
      POST https://mcp.cvent.com/mcp returns 401 with
      'WWW-Authenticate: Bearer realm="mcp", resource_metadata="https://mcp.cvent.com/.well-known/oauth-protected-resource/mcp"',
      and that URL returns HTTP 200 with resource + authorization_servers
  - id: mcp
    name: Model Context Protocol
    conforms: true
    evidence: >-
      Live remote server at https://mcp.cvent.com/mcp answering JSON-RPC over streamable HTTP with an
      RFC 9728 auth challenge. Tool set is OAuth-gated and therefore unverified — see
      mcp/cvent-hospitality-cloud-mcp.yml
  - id: oidc
    name: OpenID Connect Discovery
    conforms: partial
    evidence: >-
      https://support.cvent.com/.well-known/openid-configuration returns HTTP 200 with a full discovery
      document (issuer https://support.cvent.com), but that is the Salesforce-backed support community,
      not the API platform. api-platform.cvent.com/.well-known/openid-configuration returns 404, so the
      product API is OAuth 2.0 only, not OIDC.
  - id: rfc9457
    name: Problem Details for HTTP APIs (RFC 9457)
    conforms: false
    evidence: >-
      All 401/403/404/400/422/429 responses across the 469-operation contract use application/json with
      Cvent's own ErrorResponse envelope (code, message, details[]). No application/problem+json media
      type appears anywhere in the document.
  - id: rfc9116
    name: security.txt (RFC 9116)
    conforms: false
    evidence: >-
      /.well-known/security.txt returns 404 on www.cvent.com, developers.cvent.com,
      api-platform.cvent.com and mcp.cvent.com; 401 on support.cvent.com. See
      well-known/cvent-hospitality-cloud-well-known.yml
  - id: pagination
    name: Cursor pagination
    conforms: true
    evidence: >-
      Every list endpoint returns a paging object {limit, totalCount, currentToken}; currentToken is
      replayed as the token query parameter until absent —
      https://developers.cvent.com/docs/rest-api/reference/reference
  - id: idempotency
    name: Idempotency keys
    conforms: false
    evidence: >-
      No Idempotency-Key header, parameter or extension appears anywhere in the 469-operation contract.
      https://developers.cvent.com/docs/rest-api/explanation/concepts advises clients to "use idempotency
      keys where available" but names no mechanism, and none is documented. See
      conventions/cvent-hospitality-cloud-conventions.yml
  - id: soap11
    name: SOAP 1.1 / WSDL 1.1 / WS-I Basic Profile 1.1
    conforms: true
    evidence: >-
      "The Cvent Web services API is implemented to comply with Simple Object Access Protocol (SOAP) 1.1,
      Web Service Description Language (WSDL) 1.1, and WS-I Basic Profile v1.1 specifications." —
      https://developers.cvent.com/docs/legacy-api/soap-api/framework; contract saved at
      wsdl/cvent-hospitality-cloud-soap-v200611.wsdl
  - id: iso4217
    name: ISO 4217 currency codes
    conforms: true
    evidence: https://developers.cvent.com/docs/rest-api/reference/api-standards names ISO 4217 for currency codes
  - id: iso3166
    name: ISO 3166 country codes
    conforms: true
    evidence: https://developers.cvent.com/docs/rest-api/reference/api-standards names ISO 3166 for country codes
  - id: iso8601
    name: ISO 8601 date-times
    conforms: true
    evidence: >-
      Audit and resource timestamps are declared "The ISO 8601 zoned date time when this record was
      created" throughout components.schemas in the harvested contract
domain_standards:
  - id: scim2
    name: SCIM 2.0 (System for Cross-domain Identity Management, RFC 7643/7644)
    conforms: true
    weight: domain-standard
    evidence: >-
      The contract exposes a full SCIM 2.0 service under /scim/v2 — /scim/v2/Users, /scim/v2/Groups,
      /scim/v2/ServiceProviderConfig, /scim/v2/ResourceTypes, /scim/v2/Schemas — and declares the SCIM
      schema URNs urn:ietf:params:scim:schemas:core:2.0:User,
      urn:ietf:params:scim:schemas:extension:enterprise:2.0:User,
      urn:ietf:params:scim:api:messages:2.0:ListResponse and
      urn:ietf:params:scim:api:messages:2.0:Error, plus an ErrorScimType schema.
      Location: paths./scim/v2/* and components.schemas in
      openapi/_original/cvent-hospitality-cloud-rest-apis-openapi.json; also documented at
      https://developers.cvent.com/docs/platform/data-models/user-scim
    note: >-
      SCIM is an identity-provisioning standard, not a hospitality one. It is recorded because the
      CONTRACT declares it — an enterprise buyer who already speaks SCIM provisions Cvent users with no
      bespoke connector. The User SCIM tag carries 11 operations.
  - id: hospitality-messaging
    name: Hospitality domain standards (OTA / HTNG / GDS message types)
    conforms: false
    evidence: >-
      Searched the full 469-operation contract and the 1,309 component schemas for OpenTravel (OTA_*),
      HTNG and GDS message shapes on the Housing, Housing Hotels, RFP and Travel Suppliers surfaces.
      No OTA_/OpenTravel/HTNG message shape appears anywhere. "GDS" occurs only as opaque passthrough
      fields (externalCodes on property and room, flightGDSRecordLocator, recordLocatorGDS, noteGDS) —
      identifiers carried for someone else's system, not an implemented message standard. The hotel
      room-block, RFP and property models are entirely Cvent-proprietary (housing-event-hotel,
      room-type, reservation-request, RfpRequest, property).
    note: >-
      Recorded as an honest negative. Group-housing and venue-sourcing have no widely-adopted open
      message standard the way payments or identity do, so this is not a penalty — it is the state of
      the market.
compliance:
  certifications:
    - SOC 2
    - ISO 27001
    - ISO 27017
    - ISO 27018
    - PCI DSS
    - HIPAA
    - FedRAMP
    - GDPR
  source: https://trust.cvent.com/
  artifact: security/cvent-hospitality-cloud-trust-center.yml