Routing and failover
Your application integrates with SolidRPC once. We own the provider diversity, capability routing, health monitoring, failover, and recovery behind that integration.
On activated paid-account WebSocket networks, SolidRPC also owns native source selection and failover. Subscription IDs stay stable while sources recover. Delivery is live-only: after a client disconnect, reconnect, resubscribe and reconcile missed blocks through SolidRPC. See WebSocket coverage and recovery.
One application endpoint
Every supported network uses the same endpoint shape. The chain ID changes. The integration and authentication model do not.
https://rpc.solidrpc.io/YOUR_API_KEY/evm/{chainId}Standard reads, historical state, logs, and supported trace/debug methods travel through that route. SolidRPC chooses infrastructure that can serve the requested chain, method family, and block range. Current capabilities are published in the network catalog.
What moves to SolidRPC
Before SolidRPC
Select and contract several RPC providers
With SolidRPC
One account. One integration.Before SolidRPC
Route by chain, method, block age, and provider limits
With SolidRPC
Automatic routing by capability and upstream health.Before SolidRPC
Build fallback logic and qualify every fallback path
With SolidRPC
Qualified failover behind the same endpoint.Before SolidRPC
Monitor provider freshness, errors, and capacity
With SolidRPC
Continuous RPC-layer monitoring.Before SolidRPC
Page your team and coordinate recovery
With SolidRPC
SolidRPC owns upstream incidents and recovery.
Your team still chooses the chain and JSON RPC method required by the product. It should not need to choose, combine, monitor, or fail over between providers to execute that request.
What happens when an upstream fails
SolidRPC monitors upstream availability, freshness, latency, and capability. Routing removes an unhealthy or unsuitable path and sends eligible requests to qualified capacity without asking the application to switch URLs. Monitoring and recovery continue on our side until the failed path is safe to serve again.
The application keeps calling the same SolidRPC endpoint. Analytics show response units, success rate, latency, and traffic by chain. The internal upstream topology is not an integration surface.
Migrate with a reviewed code change
- Let the skill inspect your project. It finds your provider endpoints, supported HTTP JSON RPC traffic, WebSockets, provider specific APIs, and secret references. It then proposes a direct code change.
- Qualify with manual read only requests. Test representative recent and historical reads, logs, traces, and batches against the authenticated SolidRPC endpoint. Do not copy production traffic or send state changing calls during qualification.
- Review the local change. Inspect the Git diff and test results. Confirm that secrets are read from your project environment and that WebSockets or provider specific APIs remain explicit.
- Deploy through your normal review. Commit and deploy the approved change through your existing process. Observe application outcomes and use Git to roll back if needed. Once verified, retire unused provider credentials, alerts, and contracts. The final production state is one SolidRPC integration.
Cutover checklist
- Every required chain and method is listed in the network catalog.
- Recent, historical, archive, log, and trace fixtures pass where required.
- Peak sustained traffic and bursts fit the selected plan.
- Client timeouts and 429 handling match the published API behavior.
- Dashboards and alerts point at SolidRPC service outcomes, not old providers.
- Old provider credentials, fallback branches, and contracts have removal dates.
Start with the endpoint quickstart, review rate limits and error behavior, or start the guided migration.