Alchemy Client and API Routing Patterns

Overview

Route Alchemy work to viem, direct Data APIs, Wallet APIs v5, or Solana Web3.js without reviving the archived SDK. This workflow produces a reviewable artifact and negative-path evidence before any live side effect.

Prerequisites

• Current first-party Alchemy documentation for the selected product, chain, feature, client, authentication method, limit, and lifecycle.
• Named product, application, security, data/privacy, budget, release, and operations owners appropriate to the requested scope.
• Synthetic or approved non-production fixtures, a credential canary, explicit success criteria, and a tested rollback boundary.

Current Contract

There is no single current JavaScript Alchemy SDK for every product. EVM Node reads belong behind a viem transport adapter, Data APIs behind response-contract adapters, transacting applications behind Wallet APIs v5, and Solana behind Solana Web3.js. The archived alchemy-sdk is migration input, not a new architecture choice.

Authentication

Each adapter declares the credential it accepts and rejects other credential classes. Keep application keys, Admin access keys, Notify tokens, webhook signing keys, and wallet signing authority in separate types and secret paths.