Production

Read the authentication and response rules in the main production guide, then see Operations for safe retries, correlation, and undocumented limits.

ReplyNodes is a read-only data gateway for applications and agents. Public data operations are authenticated HTTP GET requests, and provider runtimes remain private behind the gateway. For REST use, keep REPLYNODES_API_KEY in a secret store and send it only in the Authorization header. Do not put a key in browser code, a URL, a prompt, a log, or a committed file. The Quickstart shows the common request shape and the API Reference is generated from the runtime capability contract.

Interactive MCP clients authenticate through Better Auth at https://auth.replynodes.com and use the mcp:read scope. Headless, CI, and manually configured clients can use a ReplyNodes API key. The MCP guide explains both routes and the canonical remote server at https://mcp.replynodes.com/mcp. The client does not supply an organization id; ReplyNodes resolves organization context from the authenticated identity for OAuth access.

Successful HTTP responses use { data, meta }, and errors use { error: { code, message, request_id } }. Preserve the returned request_id when you need to connect a client log to a support investigation. Before deploying a client change, re-read the API Reference for the exact operation, parameters, and response schema you depend on.

Production clients should begin by reading the main production guide before integrating an endpoint. It explains the accepted authentication forms, the response envelope, and the boundary between the public read API and the external platforms it observes. Select routes from the runtime capability document or generated OpenAPI contract instead of hard-coding assumptions from an old example. Keep the organization or API-key context used for a request under the caller's control, and never derive tenant identity from a client-supplied label or from an external provider identifier.

This service is intentionally read-only. It does not publish to social platforms, change app-store listings, submit Reddit content, or expose private browser sessions. Public data can be stale, removed, rate-limited, or unavailable upstream, so production workflows should surface uncertainty rather than promising freshness or completeness. Preserve each response's request_id, classify errors by HTTP status, and use the operations guide for safe retry behavior. When deployed behavior and a copied snippet disagree, the live capability and OpenAPI documents are authoritative; capture the discrepancy for follow-up instead of guessing.