Production operations
Use bounded timeouts, preserve the returned request_id for support, honor Retry-After on 429, and retry only safe transient reads. Do not assume quotas, SLAs, freshness, or retention periods: the repository does not publish those values. The runtime capability OpenAPI document served at /api/openapi.json remains authoritative for deployed path and schema compatibility.
All public data operations are read-only HTTP GET requests. The API key belongs in Authorization: Bearer $REPLYNODES_API_KEY; keep it in a secret store and out of browser code, URLs, prompts, logs, and commits. The API Reference is generated from the runtime capability contract, so check the exact method, path, required parameter, optional parameter, and response schema before making a production request. The Quickstart shows a complete authenticated request against https://api.replynodes.com.
Successful responses use the { data, meta } envelope. meta.request_id is always present, and the same correlation identifier is returned in X-Request-Id. Errors use { error: { code, message, request_id } }. When you provide an opaque X-Request-Id, preserve it in the client log with the request method and path. That gives support a stable correlation value without recording a secret.
For an invalid request, validate the declared parameters against the reference rather than retrying unchanged. For 429, follow Retry-After and reduce concurrency. Treat transient upstream failures as safe to retry only for reads, with a bounded timeout. Do not infer unpublished quotas, service-level agreements, freshness, or retention behavior. Read Production for authentication boundaries and MCP when the client connects through the remote MCP server.
Make retries explicit in the client: cap the number of attempts, use a finite backoff, and stop when the response indicates an invalid request, an authorization failure, or an upstream result that is not safely repeatable. Idempotent public reads can usually be retried after a connection reset or a transient server error, but a retry does not make the underlying provider data fresher or more complete. Log the endpoint, status, elapsed time, and request_id without logging credentials, cookies, or private payloads. Correlate repeated failures by request ID and time window before escalating them.
When an integration changes, validate it against the deployed capability and OpenAPI documents rather than a local guess. Check the exact route, parameter spelling, required identifiers, pagination behavior, and response envelope. Keep a small, bounded smoke request for operational checks and avoid broad crawls as a health probe. This service exposes read-only data through provider boundaries; it does not authorize writes or grant access to private third-party accounts. If a provider is unavailable, preserve the error classification and tell downstream agents that the data is unavailable instead of fabricating an empty success response.