generated: '2026-08-12' method: searched source: https://www.kixie.com/security/ name: Kixie standards conformance description: >- Cross-cutting standards and industry-regime conformance for Kixie, assessed against published evidence only. Kixie's own security page states explicitly that it "intentionally does not claim a certification, audit result, hosting architecture, retention period, or control that has not been confirmed for publication" — so the absence of certification claims below reflects Kixie's own deliberate posture and should be read as such, not as a failure to look. compliance_certifications_published: false compliance_pointer_emitted: false compliance_note: >- No SOC 2, ISO 27001, PCI DSS, HIPAA or FedRAMP claim is published anywhere on Kixie's public surface. Because none is published, this repo emits NO `Compliance` pointer in apis.yml. Kixie routes evaluators to their sales representative for security documentation instead. standards: - id: e164 name: E.164 international phone number format conforms: true strength: partial evidence: >- Kixie recommends E.164 on the PowerList API ("for best results, use E.164 phone number format") and emits normalised `tonumber164` / `fromnumber164` fields alongside loose `tonumber` / `fromnumber` in every call webhook payload. caveat: >- Input is lenient rather than strict — "most phone number formats will work fine" — so E.164 is a recommendation on the request path and a guarantee only on the response path. source: https://support.kixie.com/hc/en-us/articles/19135310564635-PowerList-API - id: oauth2 name: OAuth 2.0 conforms: false evidence: >- No authorization server, no token endpoint, no scopes, no /.well-known/oauth-authorization-server (probed 2026-08-12, no host serves one). Authentication is a single static account API key. source: authentication/kixie-authentication.yml - id: oidc name: OpenID Connect conforms: false evidence: No /.well-known/openid-configuration served on any Kixie host (probed 2026-08-12). - id: openapi name: OpenAPI Specification conforms: false evidence: >- No OpenAPI or Swagger document is published or discoverable. All spec-path probes against the docs host returned WordPress fuzzy redirects; all probes against the API gateway returned 403. source: well-known/kixie-well-known.yml - id: asyncapi name: AsyncAPI conforms: false evidence: >- Eight webhook event types are documented with payload examples, but no AsyncAPI document describes them. source: asyncapi/kixie-webhooks.yml - id: rfc9457 name: 'RFC 9457: Problem Details for HTTP APIs' conforms: false evidence: >- No application/problem+json usage; no error catalogue of any kind is published. The only documented response envelope is a proprietary {success, result} shape on the Agent Status API. source: conventions/kixie-conventions.yml - id: rfc9116 name: 'RFC 9116: security.txt' conforms: false evidence: >- /.well-known/security.txt returns 404 on www.kixie.com, developer.kixie.com and app.kixie.com. A security contact and reporting instructions ARE published, but as an HTML page only. source: well-known/kixie-well-known.yml - id: rfc8594 name: 'RFC 8594: Sunset HTTP Header' conforms: false evidence: No Sunset or Deprecation header documented; no deprecation policy published. source: lifecycle/kixie-lifecycle.yml - id: rfc9239-ratelimit-headers name: RateLimit header fields for HTTP conforms: false evidence: >- A daily quota of 10,000 calls per account is published in prose, but no RateLimit-*, X-RateLimit-* or Retry-After response header is documented. source: rate-limits/kixie-rate-limits.yml - id: idempotency-key name: Idempotency-Key HTTP header conforms: false evidence: >- No idempotency key or deduplication window on any endpoint, including the call-placing and SMS-sending operations whose side effects are irreversible. source: conventions/kixie-conventions.yml - id: webhook-signing name: Signed webhook delivery conforms: false evidence: >- No HMAC signature, shared secret, or timestamp header on webhook deliveries. Only an optional static custom header set at registration time. source: asyncapi/kixie-webhooks.yml - id: json-api name: 'JSON:API' conforms: false evidence: Proprietary payload shapes; no JSON:API media type or document structure. - id: rest name: Resource-oriented REST conforms: false evidence: >- Kixie is RPC over HTTP. One endpoint dispatches on an `eventname` string in the body; the webhook management API dispatches on a `call` string and uses POST for reads and deletes. source: conventions/kixie-conventions.yml - id: mcp name: Model Context Protocol conforms: false evidence: No MCP server published; mcp.kixie.com returns 404 (probed 2026-08-12). - id: a2a name: A2A Agent Card conforms: false evidence: >- No agent card at /.well-known/agent-card.json or /.well-known/agent.json on any host. The 301s returned by the WordPress hosts resolve to marketing HTML, not to a card. source: well-known/kixie-well-known.yml regulatory: note: >- Kixie operates a US telephony and messaging product, which places it inside a real regulatory perimeter regardless of what it certifies. These are compliance FEATURES Kixie documents, not certifications Kixie holds. regimes: - id: tcpa-dnc name: TCPA / Do Not Call registry screening posture: documented product feature conforms: partial evidence: >- Kixie ships a DNC (Do Not Call) add-on described on the pricing page as "automated compliance with Do Not Call registries", and publishes a DNC algorithm article together with an explicit legal disclaimer article. caveat: >- Sold as a paid add-on rather than included, and accompanied by a legal disclaimer — the obligation remains the customer's. sources: - https://support.kixie.com/hc/en-us/articles/16376376568859-DNC-Algorithm-for-Calls-SMS - https://support.kixie.com/hc/en-us/articles/16403691600155-Legal-Disclaimer-Do-Not-Call-Registry-Algorithm-for-Calls-SMS - id: 10dlc name: 10DLC A2P messaging registration posture: documented requirement and guidance conforms: true evidence: >- Kixie publishes 10DLC registration recommendations and prices SMS off 10DLC-registered numbers ($0.011/text), so registration is an operative part of the product. source: https://support.kixie.com/hc/en-us/articles/16188947660571-10DLC-Registration-Recommendations - id: call-recording-consent name: Two-party call recording consent posture: not documented conforms: unknown evidence: >- Call recording is a core feature on every tier and recording URLs are posted to customer webhook endpoints, but no consent, announcement or jurisdiction guidance was found in the public documentation. - id: stir-shaken name: STIR/SHAKEN caller ID attestation posture: not documented conforms: unknown evidence: >- No public statement found. Kixie does publish spam-flagging remediation and number-warmup guidance, which implies attestation is in play operationally, but it makes no claim. related: - https://support.kixie.com/hc/en-us/articles/39479985832859-Number-Warmup-Strategies-to-Avoid-Spam-Flagging - id: gdpr-ccpa name: GDPR / CCPA posture: addressed in the privacy policy only conforms: unknown evidence: >- Kixie's security page routes data-handling questions to its Privacy Policy and Terms of Use rather than making a regime claim. source: https://www.kixie.com/privacy/ summary: conformant_count: 2 non_conformant_count: 13 unknown_count: 3 finding: >- Kixie conforms to the telephony-domain standards its product cannot function without (E.164, 10DLC) and to essentially none of the HTTP API interoperability standards. The honest framing is that Kixie treats its API as an automation hook for a communications product rather than as a platform contract — and its public security posture is unusually candid about claiming nothing it has not confirmed for publication, which is worth more than an unevidenced badge.