Alchemy Installation and Authentication Intake

Overview

Select and prove the current Alchemy client, key type, network, and authentication boundary before integration work. 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

The legacy alchemy-sdk JavaScript repository is archived and deprecated. New EVM reads use viem or direct documented HTTP APIs; transacting applications and Portfolio support use @alchemy/wallet-apis; Solana work uses Solana Web3.js. An application API key, an Admin access key, a Notify auth token, and a webhook signing key are different credentials and are not interchangeable.

Authentication

Prefer server-side request-header authentication for confidential workloads. A browser key is acceptable only when the current Alchemy guidance, explicit domain allowlists, least privilege, and the product threat model allow it; short-lived JWTs are the stronger frontend option. Store Admin, Notify, webhook, and signing credentials only in approved secret storage.