generated: '2026-08-23'
method: searched
source: >-
  https://partner-api-docs.myalex.com/, https://www.jellyvision.com/security/,
  https://login.myalex.com/.well-known/openid-configuration,
  https://www.jellyvision.com/.well-known/oauth-protected-resource
standards:
- id: oauth2
  name: OAuth 2.0 (RFC 6749)
  conforms: true
  evidence: >-
    The Partner Integration API mints bearer tokens via the client_credentials grant against
    https://login.myalex.com/oauth/token with client_id, client_secret, audience and grant_type,
    returning access_token / token_type "Bearer" / expires_in — documented in the Authentication
    section of the V1 API Reference.
- id: oauth2-client-credentials
  name: OAuth 2.0 Client Credentials Grant
  conforms: true
  evidence: 'grant_type is documented as always client_credentials; two credential pairs are issued, one per environment.'
- id: rfc6750
  name: OAuth 2.0 Bearer Token Usage (RFC 6750)
  conforms: true
  evidence: >-
    Authorization header carries "Bearer <jwt>"; the MCP endpoint returns a compliant
    WWW-Authenticate: Bearer challenge with realm and resource_metadata parameters.
- id: rfc7519
  name: JSON Web Token (RFC 7519)
  conforms: true
  evidence: >-
    The docs describe the API key as "a signed JSON Web Token (JWT)" and publish a decoded example
    with iss, sub, aud, exp, iat and scope claims.
- id: oidc
  name: OpenID Connect Discovery 1.0
  conforms: true
  evidence: >-
    Both ALEX identity hosts serve a complete discovery document —
    https://login.myalex.com/.well-known/openid-configuration (HTTP 200) and
    https://login.jellydevs.com/.well-known/openid-configuration (HTTP 200) — advertising
    authorization, token, userinfo, jwks_uri, registration and revocation endpoints. Both are Auth0
    tenants. NOTE: OIDC is the identity platform's conformance; the Partner Integration API itself
    uses only the client-credentials grant and does not consume ID tokens.
- id: rfc8414
  name: OAuth 2.0 Authorization Server Metadata (RFC 8414)
  conforms: true
  evidence: >-
    https://www.jellyvision.com/.well-known/oauth-authorization-server returns HTTP 200 with issuer,
    authorization_endpoint, token_endpoint, revocation_endpoint, response_types_supported,
    grant_types_supported, code_challenge_methods_supported ["S256"] and scopes_supported ["mcp"].
- id: rfc9728
  name: OAuth 2.0 Protected Resource Metadata (RFC 9728)
  conforms: true
  evidence: >-
    https://www.jellyvision.com/.well-known/oauth-protected-resource returns HTTP 200 naming the
    resource, authorization_servers, bearer_methods_supported and scopes_supported; the MCP endpoint
    emits a matching resource_metadata parameter in its 401 WWW-Authenticate challenge.
- id: rfc7636
  name: PKCE (RFC 7636)
  conforms: true
  evidence: 'code_challenge_methods_supported ["S256"] on the www.jellyvision.com authorization server metadata.'
- id: saml2
  name: SAML 2.0 Web Browser SSO Profile
  conforms: true
  evidence: >-
    The SSO section documents a standard SAML flow, IdP-initiated by default, with an x509
    RSA-SHA256 signing certificate from a 4096-bit key and a named attribute set (partner_id,
    partner_client_id, partner_user_id, product_key, session_id, target). SP-initiated is available
    on request. Jellyvision's own status page is fronted by jellyvision.okta.com over SAML 2.0.
- id: mcp
  name: Model Context Protocol
  conforms: true
  evidence: >-
    A live MCP server responds to JSON-RPC POSTs at
    https://www.jellyvision.com/wp-json/mcp/mcp-oauth-server with an OAuth challenge; see
    mcp/jellyvision-mcp.yml. Tool-level conformance could not be graded because tools/list is gated.
- id: llmstxt
  name: llms.txt
  conforms: true
  evidence: 'https://www.jellyvision.com/llms.txt returns HTTP 200; generated by Yoast SEO v28.2.'
- id: rfc9457
  name: Problem Details for HTTP APIs (RFC 9457)
  conforms: false
  evidence: >-
    Errors use a bespoke envelope (userId, requestId, success, warnings, errors) with plain-string
    error entries and application/json — no type URI, no application/problem+json, no per-field
    error objects. See errors/jellyvision-problem-types.yml.
- id: rfc8594
  name: Sunset Header (RFC 8594)
  conforms: false
  evidence: 'No Sunset or Deprecation header and no deprecation policy is documented.'
- id: pagination
  name: Collection pagination
  conforms: false
  evidence: 'No endpoint returns a paged collection; no pagination parameters are documented.'
- id: idempotency
  name: Idempotency-Key
  conforms: false
  evidence: >-
    No Idempotency-Key header is documented. POST /api/partner/user is a documented natural-key
    upsert, which is retry-convergent, but POST /api/partner/session creates a new session per call.
    See conventions/jellyvision-conventions.yml.
- id: openapi
  name: OpenAPI Specification
  conforms: false
  evidence: >-
    No OpenAPI or Swagger document is published. The V1 API Reference is a static Slate-style HTML
    page on S3; /openapi.json, /openapi.yaml and /swagger.json on the docs host all return HTTP 404
    (S3 NoSuchKey), and the same paths on api.myalex.com return HTTP 404 JSON.
- id: asyncapi
  name: AsyncAPI
  conforms: false
  evidence: 'No event, streaming or webhook surface is documented anywhere in the V1 API Reference.'
domain_standards:
  note: >-
    Reward-only check. Jellyvision operates in US employee benefits enrollment, a market that does
    have real interchange standards — X12 EDI 834 Benefit Enrollment and Maintenance is the dominant
    one for carrier/employer eligibility exchange, and LIMRA/ACORD shapes appear in voluntary
    benefits. The ALEX Partner Integration API DECLARES NONE OF THEM. Its plan, premium-tier and
    contribution model is entirely proprietary: partner-defined plan codes (partnerCode) mapped to
    Jellyvision-issued plan codes (alexCode), and coverage expressed as Jellyvision tier codes 10-90
    under seven proprietary tierCoverageTypeId shapes. There is no 834 segment, no ACORD schema, no
    FHIR resource and no SCIM/OData/OAuth-domain-profile surface in the contract. Recorded as absent,
    not as a penalty.
  declared: []
  probed_for:
  - X12 EDI 834 Benefit Enrollment and Maintenance
  - ACORD
  - FHIR (HL7)
  - SCIM (urn:ietf:params:scim:schemas:*)
  - OData $metadata
  integration_consequence: >-
    A benefits administration platform already speaking 834 cannot reuse it here; every partner must
    build a bilateral mapping from its own plan codes into ALEX's partnerCode/alexCode and tier-code
    model. That mapping cost is the practical meaning of this row.
compliance:
  certifications:
  - name: SOC 2
    source: https://www.jellyvision.com/security/
    evidence: Named explicitly on the Data Security & Privacy Commitment page.
  - name: HIPAA
    source: https://www.jellyvision.com/security/
    evidence: >-
      Named explicitly on the Data Security & Privacy Commitment page. Material given the product
      handles employee medical plan selection and claims-informed guidance.
  trust_center:
    url: https://trust.jellyvision.com/
    status: 200
    readable: false
    note: >-
      A real, provider-operated trust center exists at trust.jellyvision.com and returns HTTP 200,
      but it is an Angular single-page application (apps/trustcenter/main.*.js) that renders its
      entire contents client-side. The served HTML contains only the string "Trust Center" — no
      certification names, no framework list, no subprocessor table and no document index survive
      without JavaScript execution, and the bundle exposes no readable API base. The certifications
      recorded above therefore come from the statically rendered /security/ page, not from the trust
      center itself.
  audits:
    internal_security_audits: true
    source: https://www.jellyvision.com/security/
  privacy:
    privacy_policy: https://www.jellyvision.com/privacy-policy/
    privacy_choices: https://www.jellyvision.com/privacy-choices/