GPT Actions
ChatGPT-facing actions use OAuth-style authorization flows and scoped server-side access rather than direct exposure of private app sessions.
Back to docs
Rilev Integrations Guide
Integrations extend Rilev, but they should not weaken the platform's privacy boundaries. This guide explains the trust model around machine clients, authorization grants, live context, and provider callbacks.
MCP-style workflows
Machine clients should receive narrow capabilities and explicit tool boundaries, not broad database access or user-controlled account identifiers.
Live context grants
Context sharing should remain session-bound, time-bounded, and revocable so integrations do not become hidden persistence channels.
Authorization exchange
Authorization grants are intended to be short-lived, narrowly scoped, and protected according to the integration model.
Provider callbacks
Stripe, RevenueCat, and similar provider callbacks rely on provider verification, not browser-origin assumptions.
Privacy inheritance
Integrations must inherit the same anonymity and data-plane boundaries as the core product instead of bypassing them.
Integration rule
A new integration should answer three questions before it ships: what capability is granted, how the grant expires or revokes, and whether the integration can accidentally join identity-plane and data-plane records.
Rilev's integration docs should stay explicit about public machine surfaces while keeping implementation-sensitive route details inside internal engineering docs.