The séance communication API presents unique integration challenges that standard REST documentation frameworks were not designed to address. The endpoint is unreliable by nature, authentication is non-deterministic, and the SLA does not cover cases where the requested spirit simply declines to participate.
Authentication begins with session establishment, which in séance terminology requires a quorum of participants, appropriate atmospheric conditions, and a sufficiently resonant opening invocation. Token-based auth is not currently supported. API key management is replaced by a relationship-dependent trust model that behaves inconsistently across sessions.
Rate limiting is imposed by the underlying medium rather than the infrastructure layer. Most séance endpoints support between one and three successful communications per hour under optimal conditions. Requests that exceed this threshold typically result in degraded response quality, ambient noise artifacts, or a 429-equivalent that manifests as candles going out.
Latency is the primary performance concern. The average response time from a séance endpoint ranges from several minutes to never, with the distribution heavily weighted toward the longer end. Applications that depend on sub-second response times should architect around this constraint with aggressive timeout handling and graceful degradation.
Payload format is not standardized. Responses arrive as verbal utterances, table vibrations, Ouija board letter sequences, or environmental phenomena that require client-side interpretation. JSON is not natively supported. A translation middleware layer is recommended for any application that needs structured data.
Retry logic must be implemented carefully because aggressive retry behavior on a séance endpoint is considered discourteous by the provider and may result in rate limit reduction, session termination, or a response that escalates the situation unhelpfully.
Error handling should cover the most common failure modes. A null response indicates no connection was established. An ambiguous response requires disambiguation logic. An escalated response, where the session produces output that was not requested and cannot be easily terminated, is a rare but documented edge case that the application should handle gracefully.
Webhooks are not currently offered by any séance provider at scale. Push notification support is theoretically available through haunting-based channels, but the delivery guarantee is poor and the format is completely unstandardized.
Security considerations include the risk of connecting to an unintended endpoint, which in séance terminology is sometimes called contacting the wrong spirit. Input validation and endpoint verification before session establishment are strongly recommended.
Documentation for this API is necessarily incomplete because the provider does not maintain a developer portal, changelog, or deprecation policy. Production integrations should build in maximum tolerance for undocumented behavior and budget for regular regression testing whenever ambient conditions change significantly.