Helius API documentation, May 2026

Prepared for: Helius, Developer Documentation team Date of review: 2026-05-28 (substrate); revised v3 2026-05-31 Documents reviewed: www.helius.dev/docs documentation corpus mirrored 2026-05-28 — 659 files (~9900 KB) covering 8 product surfaces (Solana RPC HTTP, Digital Asset Standard / DAS, Sender, Wallet API, Priority Fee, ZK Compression, Admin, Webhooks) plus the Enhanced API surface (legacy), plus narrative sections (Billing, Quick Start, RPC Guides, LaserStream Guides, Agent Onboarding, Wallet API, Webhooks, Sending Transactions, FAQs, Glossary, Support), plus 9 standalone OpenAPI 3.x JSON specifications, plus an agent-onboarding document (AGENTS.md), plus a top-level + bundled llms.txt pair, plus an RFC 9727 linkset (_api-catalog.txt), plus a parallel Chinese (zh/) localization tree Review type: Documentation quality, correctness, and developer-integration-readiness assessment across Helius's Solana infrastructure API ecosystem

---

Revision note — what changed in v3

This revision corrects three issues in the prior draft after re-reconciling each finding against the full corpus (OpenAPI specifications and the narrative documentation):

1. F-1 reassessed from CRITICAL to MEDIUM. The prior draft graded the Sender API http:// server URLs as a critical security exposure on the assumption that plaintext regional endpoints were unintended. Cross-referencing the Sender narrative documentation (sending-transactions/sender.md) shows the regional HTTP endpoints are a documented, intentional design choice for server-to-server latency, with the global HTTPS endpoint explicitly recommended for browser/frontend use. The OpenAPI specification is therefore consistent with the published guidance, not contradicting it. A genuine but narrower finding remains — the documentation does not warn developers about the confidentiality tradeoff of submitting signed transactions over plaintext — and is regraded accordingly. There is no spec-vs-reality contradiction and no basis for a security advisory.

1. F-2 occurrence count corrected. The Webhooks specification contains 7 x-amazon-apigateway-integration blocks (14 placeholder strings: 7 × view-layer DNS, 7 × VPC-link ID), not 8. The merged catalog contains 21 such blocks. The finding itself stands and is now the highest-priority genuine item in the report.

1. F-3 reassessed from HIGH to MEDIUM. The merged catalog is described in the agent-onboarding document as covering REST surfaces, and the surfaces it omits (RPC HTTP, DAS, Priority Fee, ZK Compression) are JSON-RPC surfaces. The "27 of 106 endpoints" gap is therefore partly an artifact of scope labelling rather than a clean defect. The residual legitimate issues (ambiguous scope label; no standalone Enhanced API specification) are retained.

Several findings previously graded HIGH on cross-specification consistency grounds (F-4, F-5, F-6, F-8) are regraded MEDIUM: they are real and worth fixing, but their developer impact is hygiene/polish rather than integration-blocking. F-7 (Webhooks host conflict) remains HIGH because it concretely prevents a developer from determining the canonical host from documentation alone.

Net severity change: 0 Critical (was 1), 2 High (was 7), 16 Medium (was 10), 3 Low (unchanged). Total findings unchanged at 21; finding IDs are stable across v2 → v3 for traceability.

---

Executive summary

The Helius API documentation set is structurally complete (657 of 659 enumerated URLs returned 200; the 2 misses are both Chinese-language pages with English equivalents present) and serves its primary purpose: documenting the Solana RPC and infrastructure platform across an extensive set of API surfaces. The corpus is best-in-class on several dimensions:

• The rate-limit + retry-policy + autoscaling documentation is the most thorough encountered (explicit HTTP 429 surfacing; exponential-backoff guidance; per-endpoint credit-cost tables; autoscale credit-acquisition mechanism documented).
• Component-schema $ref discipline is applied in 7 of 8 standalone OpenAPI specifications, producing clean typed-client codegen surfaces for those specs.
• The documentation-build pipeline uses the canonical www.helius.dev host consistently across the documentation-index banner (658 of 659 pages), sitemap.xml, and the RFC 9727 linkset — a positive coordination state at the documentation surface.
• The agent-onboarding infrastructure (AGENTS.md + llms.txt + llms-full.txt + RFC 9727 linkset + .well-known/agent-card.json + MCP server card) is a sophisticated set of agent-discoverability artifacts.

The corpus carries 21 findings across the documentation quality dimensions reviewed.

Documentation is usable for integration and visibly mature. No finding rises to a security-critical or integration-blocking severity. The two highest-priority items are both publishing-hygiene issues in the OpenAPI surface: an internal-infrastructure metadata leak in the Webhooks specification (F-2) and a three-way host disagreement for the Webhooks API across documentation channels (F-7).

Top-priority items requiring attention:

The HIGH-severity items concentrate on OpenAPI publishing hygiene and cross-document host coordination. The Webhooks specification leaks x-amazon-apigateway-integration blocks carrying unsubstituted build-time placeholders (PLACEHOLDER_VIEW_LAYER_DNS_NAME, PLACEHOLDER_VPC_LINK_ID) — these reveal backend topology and indicate a publication-pipeline substitution gap, and should be filtered out of public specifications. Separately, a developer constructing the Webhooks URL faces three candidate hosts across the agent doc, the per-API spec, and the merged spec, with no single authoritative source.

---

Methodology

The review was a systematic read-through of every file in the documentation mirror, applying a documentation-quality checklist for vendor-published REST + JSON-RPC API surfaces, with extensions for Helius's multi-product architecture, Mintlify-platform authoring pattern, multi-format OpenAPI publication (standalone JSON + GitHub-hosted YAML + Mintlify-inline-YAML), agent-onboarding infrastructure, and Chinese-language parallel localization. The checklist covered:

• Content integrity (per-endpoint title ↔ tags ↔ path ↔ parameter set internal consistency)
• Response schema completeness and required/optional field marking
• Identifier and endpoint canonicity (base URLs, version paths, auth header naming, host fragmentation)
• Cross-product canonicity (security schemes, version-numbering, server-URL conventions, parameter vocabularies across the 8 product surfaces)
• Documentation host coordination (sitemap host vs canonical host vs banner host vs linkset host)
• API host coordination (server URLs in standalone specs vs agent doc vs merged catalog vs linkset)
• Spec-vs-narrative reconciliation (every OpenAPI-level observation cross-checked against the corresponding prose documentation before grading)
• BETA / preview surface lifecycle policy
• Schema definition reuse across endpoint specifications (component-schema $ref discipline)
• Documentation-index banner positioning and content
• Code sample correctness against current SDK versions
• Deprecation and lifecycle hygiene (dates, deprecated field markers, replacement pointers, version coexistence)
• Cross-link and cross-reference integrity (internal links resolve; rate-limit-table endpoints all have reference docs)
• Security scheme metadata consistency (top-level vs per-operation security; auth-header naming; multi-scheme operations)
• Renderer portability (markdown vs JSX-wrapped content)
• Internationalization coverage (parallel language structure; translation-currency; 404s on translated pages)
• Standalone-vs-inline OpenAPI canonicity (multiple format/host publication paths)
• Agent-discoverability infrastructure coordination (AGENTS.md ↔ llms.txt ↔ llms-full.txt ↔ linkset ↔ MCP server card)

Each finding was severity-graded against developer-impact criteria:

• Critical — Security exposure with no documented mitigation, OR reader misled into a wrong integration path with class-wide surface affected
• High — Material integration friction; non-obvious workaround required
• Medium — Friction reducible by reader effort; doc quality observable
• Low — Cosmetic inconsistency; affects polish, not function

Substrate verification was mechanical and reproducible: file counts, OpenAPI title/version distributions, server-URL declarations, server-URL-protocol counts, host-frequency counts, schema body comparisons, security-scheme distributions, JSX-wrapper counts, and Chinese-language file parity were performed via grep / diff / awk / Python over the local mirror.

Finding IDs (F-1 through F-21) are opaque sequence numbers with no semantic content outside this report.

---

Findings

High

F-2 — AWS API Gateway internal infrastructure metadata leaked into the public Webhooks OpenAPI specification

Unchanged Re-check of the published text, 11 October 2026.

Category. Information disclosure — internal build-pipeline placeholder strings in published spec Affected files. _openapi/webhooks.json, propagated into _openapi/_merged.json.

Observation. The Webhooks OpenAPI specification contains 7 x-amazon-apigateway-integration extension blocks, each carrying placeholder strings:

"x-amazon-apigateway-integration": {
  "httpMethod": "GET",
  "type": "http_proxy",
  "uri": "http://PLACEHOLDER_VIEW_LAYER_DNS_NAME/webhooks",
  "connectionType": "VPC_LINK",
  "connectionId": "PLACEHOLDER_VPC_LINK_ID"
}

7 such blocks in webhooks.json (14 placeholder occurrences: 7 × PLACEHOLDER_VIEW_LAYER_DNS_NAME, 7 × PLACEHOLDER_VPC_LINK_ID); 21 such blocks in the merged catalog (which aggregates additional Enhanced API endpoints with the same pattern). The placeholder strings indicate the OpenAPI document was generated from a templated source with build-time variable substitution, but the substitution was not performed before public publication.

Developer impact.

• The x-amazon-apigateway-integration extension is AWS API Gateway tooling-specific configuration; it is not intended for publication in customer-facing OpenAPI specifications. Its publication reveals backend hosting on AWS API Gateway with VPC Link integration and an internal "view layer" naming convention.
• The placeholders themselves are not exploitable (literal strings, not active references), but their presence indicates either a silent substitution failure during publication, or a deliberate but purposeless inclusion — in either case the blocks serve no consumer function and should be stripped.

Recommendation. Strip x-amazon-apigateway-integration extensions from public OpenAPI files via the publication pipeline (filter x-amazon-* extensions before publication), OR replace PLACEHOLDER_* values with public-canonical URIs if the metadata is intended to remain. Add a published-spec verification step that fails the build on any x-amazon-* extension or PLACEHOLDER_* string in published-tier files.

---

F-7 — Three different hosts cited for the Webhooks API across documentation channels

Unchanged Re-check of the published text, 11 October 2026.

Category. Cross-document host coordination Affected files. AGENTS.md, _openapi/webhooks.json, _openapi/_merged.json, _openapi/_api-catalog.txt.

Observation. The Webhooks API is referenced at different host URLs across channels:

A developer constructing the Webhooks URL faces conflicting candidates. Each document is internally consistent within itself, but they disagree at the host axis, so the canonical host cannot be determined from documentation alone — the developer must test connectivity to each candidate.

The deeper issue is host topology: Helius uses three root domains (helius.dev, helius.xyz, helius-rpc.com) with subdomain proliferation, and each product surface uses its own host. This is defensible architecturally (RPC-tier hosts optimized for throughput; REST-tier hosts for routing; Sender regional endpoints distributed for latency), but it is undocumented.

Recommendation.

• Pick one canonical Webhooks host and update all four documents (AGENTS.md, webhooks spec, merged spec, linkset) to match.
• Consider publishing a host-architecture overview page documenting the rationale for the multi-host topology.
• Add a documentation-pipeline assertion that the host citation for each surface is consistent across the AGENTS.md row, per-API spec server, merged-spec server, and linkset anchor.

---

Medium

F-1 — Sender API regional endpoints transmit signed transactions over plaintext HTTP, with no security-tradeoff note in the documentation

Unchanged Re-check of the published text, 11 October 2026.

Category. Security documentation — confidentiality-tradeoff guidance missing Affected files. _openapi/sender-api.json, _openapi/_merged.json, sending-transactions/sender.md.

Observation. The Sender API per-API specification declares 8 server URLs; 7 use http:// (the regional endpoints) and only the global aggregator https://sender.helius-rpc.com uses https://. The same 7 http:// URLs propagate into the merged catalog.

This is not a spec-vs-reality contradiction. The Sender narrative documentation (sending-transactions/sender.md) documents the split intentionally: the global HTTPS endpoint is recommended for frontend/browser applications (and resolves CORS preflight issues), while the regional HTTP endpoints are presented under a "Backend/Server Applications" heading as the option for "optimal server-to-server latency." Plaintext HTTP avoids the TLS handshake round-trip — a deliberate latency optimization for backend/colocated infrastructure submitting time-sensitive transactions. The specification and the prose agree.

The genuine gap is that neither the specification nor the narrative warns developers about the confidentiality tradeoff. Submitting over http:// transmits signed transaction bytes (instructions, recent blockhash, signer signature) in plaintext, observable in flight by any on-path party (upstream proxy, ISP, shared WiFi, packet capture). The signature binds the transaction content so an observer cannot trivially mutate it, but observation alone discloses signer activity, destinations, and amounts, and may inform timing/replay-window behaviour before finalization. A developer following the "use the nearest regional endpoint" guidance on an untrusted network inherits this exposure without being told.

Developer impact.

• Backend developers on trusted/colocated networks are the documented target audience, and for them the tradeoff is reasonable.
• Developers who follow the regional-endpoint guidance from a less-trusted network (e.g., a developer testing from a laptop, or infrastructure transiting shared links) expose transaction contents without an explicit warning to prompt a different choice.

Recommendation.

• Add an explicit security note to sending-transactions/sender.md (and ideally to the Sender OpenAPI description) stating that the regional endpoints are plaintext HTTP by design, that they should be used only over trusted/colocated network paths, and that the global HTTPS endpoint should be preferred when the network path is not fully controlled.
• Consider offering HTTPS variants of the regional endpoints for developers who want regional latency and TLS, even if the default remains HTTP.
• Optionally annotate the 7 regional servers entries in the spec with a description that names the plaintext tradeoff, so codegen consumers surface it in generated client comments.

---

F-3 — Merged OpenAPI catalog scope is ambiguous, and the Enhanced API surface has no standalone specification

Unchanged Re-check of the published text, 11 October 2026.

Category. Specification scope labelling and completeness Affected files. _openapi/_merged.json, AGENTS.md, individual per-API specifications.

Observation. Summing paths across the 8 individual per-API specifications yields 106 endpoint paths (1 Admin + 12 DAS + 1 Priority Fee + 57 RPC HTTP + 2 Sender + 6 Wallet + 2 Webhooks + 25 ZK Compression). The merged catalog (_merged.json) contains 27 paths covering the legacy Enhanced API surface plus Webhooks, Wallet, Sender, and Admin. It omits RPC HTTP, DAS, Priority Fee, and ZK Compression.

This omission is partly by design rather than a defect: the agent-onboarding document describes /openapi.json as a "merged OpenAPI catalog across all REST surfaces," and the omitted surfaces (RPC HTTP, DAS, Priority Fee, ZK Compression) are JSON-RPC surfaces, not REST. Under the "REST surfaces" reading, the merged catalog's scope is coherent. The residual issues are:

• Ambiguous scope label. The agent doc refers to /openapi.json in one place simply as "the merged catalog" and elsewhere as "across all REST surfaces." A developer who reads the former without the latter may expect a true union of every surface and be surprised to find ~25% of the documented endpoints.
• No standalone Enhanced API specification. The Enhanced API endpoints appear in the merged catalog and are billable (per billing/credits.md and billing/rate-limits.md), but there is no enhanced-api.json standalone spec — the convention every other surface follows.

Recommendation.

• Make the scope label unambiguous wherever /openapi.json is referenced (e.g., consistently "Merged catalog of REST surfaces (Enhanced API, Webhooks, Wallet, Sender, Admin)"). If a true all-surfaces union is also intended to exist, publish it at a distinct, clearly-named path.
• Publish a standalone enhanced-api.json so the per-API spec set is complete against the Enhanced API billing rows. Consider renaming _merged.json to reflect its actual REST-surface scope.

---

F-4 — info.title cross-specification inconsistency: 8 distinct naming patterns across 8 standalone specifications

Unchanged Re-check of the published text, 11 October 2026.

Category. Specification taxonomy — inconsistent product naming Affected files. All 8 standalone OpenAPI specifications.

Observation. The 8 info.title values:

Three prefix conventions co-exist: Helius <Product> (Admin, Sender), Solana <Capability> (DAS, Priority Fee, RPC, State Compression), and bare <Capability> (Wallet). The merged catalog adopts a 4th convention, "Helius API Catalog." The Webhooks file is the most misleading, titled "Helius API" with no indication it documents only Webhooks.

Developer impact. Typed-client codegen against the per-endpoint specs emits 8 inconsistently-named packages; the "helius-api" name (for Webhooks) suggests a top-level all-surfaces client when the contents are Webhooks-specific.

Recommendation. Standardize a per-product convention (recommended: Helius <Product> API) and bulk-rename across the 8 specs. Reserve Solana <Capability> naming for content that ports cleanly to other Solana RPC vendors (i.e., the standard RPC HTTP surface). Rename the Webhooks file's info.title to Helius Webhooks API.

---

F-5 — info.version inconsistency across OpenAPI specifications

Unchanged Re-check of the published text, 11 October 2026.

Category. Specification versioning — mixed version values without coherent policy Affected files. All 8 standalone OpenAPI specifications.

Observation. The info.version values: 6 specifications at 1.0.0 (Admin, DAS, Priority Fee, RPC HTTP, Sender, Wallet); 1 at 1.0.1 (Webhooks); 1 at 0.50.0 (ZK Compression). The 0.50.0 value is a pre-1.0 outlier; the Webhooks patch-bump is the only non-1.0.0 revision signal. These choices do not correlate with surface lifecycle marketing — ZK Compression is positioned as production-ready in narrative docs but its spec declares 0.50.0.

Developer impact. A developer with semver-aware codegen reads ZK Compression as pre-1.0-unstable and the others as 1.0-stable; if info.version gates consumption decisions, ZK Compression is gated out incorrectly.

Recommendation. Choose a per-product versioning policy and apply it consistently — all 1.0.0 (consistent but signal-empty), version-reflects-revision, or version-reflects-lifecycle (BETA 0.x / GA 1.x.y). Either bump ZK Compression to 1.0.0 to match its GA narrative, or add explicit BETA notices to the zk-compression/* docs if 0.50.0 is intentional.

---

F-6 — OpenAPI standard-version inconsistency: 7 specifications at 3.1.0, 2 at 3.0.3

Unchanged Re-check of the published text, 11 October 2026.

Category. Specification standard version — mixed standard versions complicate tooling Affected files. _openapi/wallet-api.json (3.0.3), _openapi/webhooks.json (3.0.3); 7 specifications at 3.1.0.

Observation. OpenAPI 3.0 and 3.1 are not byte-compatible at the schema layer: 3.1 has full JSON Schema 2020-12 alignment; 3.0 uses nullable: true where 3.1 uses type: [..., 'null']; tuples, plural examples, and other features differ. Wallet and Webhooks at 3.0.3 appear to predate the 3.1 migration that produced the other 6 specs.

Developer impact. A codegen toolchain may not accept both versions in a single run; consistency across the full surface requires a both-version-capable tool or two passes. A developer reading multiple specs side-by-side sees differing nullability authoring, which can falsely suggest differing nullability semantics.

Recommendation. Upgrade Wallet and Webhooks to 3.1.0; convert nullable: true to type: [..., 'null']; standardize JSON Schema dialect alignment across all 8 specs. Add a pipeline assertion that all spec files declare the same openapi value.

---

F-8 — Path versioning inconsistency across REST surfaces (v0 vs v1, no published policy)

Unchanged Re-check of the published text, 11 October 2026.

Category. Path versioning policy Affected files. _openapi/wallet-api.json (/v1/wallet/...), _openapi/webhooks.json (/v0/webhooks), _openapi/admin-api.json (/v0/admin/...), Enhanced API endpoints in the merged catalog (mix of /v0/ and /v1/).

Observation. Wallet uses /v1/; Webhooks and Admin use /v0/; the Enhanced API shows both prefixes co-existing. No documentation clarifies whether /v0 means "legacy but canonical" (no plan to bump) or "pre-stable" (next version at /v1).

Developer impact. A developer cannot tell whether a /v0/webhooks integration is on a stable path or one destined for deprecation in favour of /v1/webhooks, and the Wallet /v1/ surface gives no signal about whether earlier /v0/ wallet surfaces existed.

Recommendation. Publish a path-versioning policy clarifying the meaning of /v0 vs /v1, whether /v0 surfaces will be promoted and on what timeline, and the deprecation policy when a new /v1 is added.

---

F-9 — Top-level security declaration inconsistency across OpenAPI specifications

Unchanged Re-check of the published text, 11 October 2026.

Category. Specification security-metadata authoring Affected files. All 8 standalone OpenAPI specifications.

Observation. Top-level security is declared in 3 specifications (Admin, Wallet, Webhooks) and absent in 5 (DAS, Priority Fee, RPC HTTP, Sender, ZK Compression). Of the 5 without it, DAS declares per-operation security on all 12 operations; the other 4 declare neither, relying on implicit api-key-query handling. From the specification alone, a developer cannot determine whether unauthenticated calls return 401 or 200, and the specs also differ on whether components.securitySchemes is declared at all.

Recommendation. Pick one convention — every spec declares top-level security (recommended), or every spec declares per-operation security. Ensure components.securitySchemes is declared whenever any security reference is used. Add a pipeline verification step asserting security-declaration consistency.

---

F-10 — DAS API specification uses zero components.schemas; all 85+ response schemas are inlined

Unchanged Re-check of the published text, 11 October 2026.

Category. Schema-reuse discipline — within-specification duplication Affected files. _openapi/das-api.json.

Observation. The DAS specification declares zero components.schemas. All 12 operations × ~7 response codes (~85 inlined schemas) are declared per-operation, and the error responses are byte-identical across all 12 operations (e.g., the 401 schema repeats verbatim 12 times). DAS is the outlier within the spec set; the 7 sibling specifications all use components and $ref extensively (RPC HTTP 61 components / 369 $ref; Webhooks 72 / 176; ZK Compression 38 / 307; Wallet 15 / 51; Priority Fee 3 / 3; Admin 2 / 6; Sender 1 / 5).

Developer impact. Typed-client codegen against DAS emits 12 duplicate Asset definitions and 12 duplicate error-response definitions; the other 7 specs encourage shared-type codegen, so DAS produces a fragmented client inconsistent with its siblings.

Recommendation. Refactor DAS to use components.schemas: define a shared Asset schema referenced from the asset-returning operations, and shared error-response schemas (400/401/403/404/429/500) referenced from every operation, bringing DAS in line with the 7 sibling specs.

---

F-11 — _llms.txt enumerates ~24 URLs vs the documentation set's 659 URLs (~96% coverage gap)

Partly fixed Re-check of the published text, 11 October 2026.

Category. Agent-discoverability infrastructure — llms.txt incompleteness Affected files. _llms.txt, _sitemap_docs.xml.

Observation. The top-level _llms.txt enumerates roughly 24 URLs under "API Surfaces", "Discovery Surfaces", "Repos", and "Support"; the sitemap enumerates 659 documentation URLs. Coverage is ~3.6%. This is acknowledged in _llms-full.txt, which notes that per-product llms.txt files are planned for follow-up.

Developer impact. An LLM agent or tool reading _llms.txt as its authoritative discovery surface — the intended use of the convention — misses the large majority of the documentation, seeing high-level structure but not individual endpoint pages or product-specific guides.

Recommendation. Deliver the planned per-product llms.txt files OR enrich the top-level _llms.txt to enumerate the api-reference per-endpoint pages and major narrative sections; at minimum, link out to whatever section-level llms.txt files exist (see F-12).

---

F-12 — Section-level llms.txt files advertised in sitemap.xml (14 entries) but not all reachable in the mirror

Could not check Re-check of the published text, 11 October 2026.

Category. Agent-discoverability infrastructure — advertisement vs availability Affected files. _sitemap_docs.xml, mirror file _llms.txt.

Observation. The sitemap advertises 14 section-level llms.txt URLs (e.g., /docs/api-reference/das/llms.txt, /docs/api-reference/rpc/http/llms.txt). The mirror captured only the top-level _llms.txt; the 14 section-level files were not fetched. This is partly a mirror-coverage limitation (the fetch did not extend to section-level llms.txt URLs), but it means parent-vs-section consistency cannot be cross-validated from this substrate.

Recommendation. Vendor side: confirm all 14 section-level llms.txt URLs return 200 as advertised. Mirror side: extend the fetch to include these files in the next refresh to enable cross-validation.

---

F-13 — Enhanced API is billable and present in the merged catalog, but has no standalone OpenAPI specification

Fixed Re-check of the published text, 11 October 2026.

Category. Specification completeness — per-API-spec convention break Affected files. _openapi/ (missing enhanced-api.json); billing/credits.md, billing/rate-limits.md; _openapi/_merged.json.

Observation. Helius publishes 8 standalone OpenAPI specs (one per surface). The Enhanced API is absent from that set despite being billable (billing/rate-limits.md rate tiers; billing/credits.md per-endpoint credit costs), absent from the AGENTS.md surfaces table, and present only in the merged catalog. The linkset points its service-desc to a GitHub-hosted YAML counterpart rather than a /openapi/enhanced-api.json JSON like every other surface.

Recommendation. Publish _openapi/enhanced-api.json standalone to align Enhanced API with the per-API convention. (This overlaps with F-3; resolving them together is recommended.)

---

F-14 — Documentation-index banner positioned before the page H1 across 658 of 659 documents

Unchanged Re-check of the published text, 11 October 2026.

Category. Documentation structure — banner displaces H1 Affected files. All 658 mirrored documents except AGENTS.md.

Observation. Every documentation page begins with a 3-line blockquote pointing to the documentation index, before the page's H1 title. This shifts anchor offsets by ~4 lines and means each page's actual subject begins at line 5+. Positive: the banner host (www.helius.dev) is canonical and consistent across all 658 pages.

Developer impact. The banner-before-H1 pattern is non-idiomatic for markdown; anchor offsets are systematically shifted; print/source views begin every page with the same boilerplate.

Recommendation. Relocate the documentation-index reference to a per-page footer or an inline block after the H1, decoupling it from the top-of-file position.

---

F-15 — Two Chinese-language pages return 404 while English equivalents are present

Fixed Re-check of the published text, 11 October 2026.

Category. Internationalization — translation incompleteness Affected files. zh/laserstream/guides/slot-and-block-monitoring, zh/wallet-api/funded-by.

Observation. The mirror captures a parallel Chinese localization (332 EN + 327 ZH pages) with directory parallelism across major sections. Two Chinese pages returned 404 at mirror time, while their English equivalents mirrored successfully. The Wallet API EN=6 / ZH=5 parity gap is attributable to the second 404.

Developer impact. A Chinese-language developer following internal navigation hits dead-ends silently and may not realize an English version exists.

Recommendation. Complete the two missing translations, OR provide a parent-language fallback (serve English with a "translation pending" banner when a zh/ page is absent), OR explicitly mark in-progress surfaces.

---

F-16 — Agent-onboarding table, RFC 9727 linkset, and OpenAPI info.title values disagree on surface naming for 4+ of 8 surfaces

Unchanged Re-check of the published text, 11 October 2026.

Category. Cross-document surface-naming inconsistency Affected files. AGENTS.md, _openapi/_api-catalog.txt, individual _openapi/*.json info.title.

Observation. Each surface name appears in three places (AGENTS.md row, linkset row title, OpenAPI info.title), and these diverge for several surfaces — e.g., DAS (acronym vs suffix vs prefix), Sender (three distinct names), Webhooks (the generic "Helius API" title), ZK Compression (OpenAPI uses "Solana State Compression API," a different product name). Wallet API is the one fully-aligned surface.

Recommendation. Pick canonical naming per surface and apply uniformly across the AGENTS.md row, linkset row title, and info.title. Consider deriving two of the three from a single source via the build pipeline.

---

F-17 — Admin API is a single-endpoint surface vs agent-doc framing of "project usage, billing"

Unchanged Re-check of the published text, 11 October 2026.

Category. Specification completeness vs narrative-framing mismatch Affected files. _openapi/admin-api.json, AGENTS.md.

Observation. The Admin API contains exactly one path (/v0/admin/projects/{id}/usage), but the agent doc frames Admin as "project usage, billing" — a 2-capability framing. No billing endpoints exist in the spec; the billing surface lives in narrative docs only and is presumably mediated by a separate control plane.

Recommendation. Either expand the Admin API to cover consumer-managed billing operations, rename the surface to "Admin Usage" to match the single-endpoint scope, fold Admin into a broader "Account Management" surface, or document that billing is managed via the dashboard (not the API) and adjust the AGENTS.md framing.

---

F-18 — JSON-RPC method discrimination via URL fragments in OpenAPI paths (non-standard convention)

Unchanged Re-check of the published text, 11 October 2026.

Category. Specification convention — non-idiomatic JSON-RPC encoding in OpenAPI Affected files. _openapi/rpc-http.json (57 operations), _openapi/das-api.json (12 operations).

Observation. The RPC HTTP and DAS specs encode JSON-RPC method discrimination via URL-fragment-as-path-key (/, /#getBalance, /#getBlock, …). Per RFC 3986, fragments are client-side-only and not received by servers; the actual request is POST / with the method in the body. OpenAPI paths here are metadata used as operation discriminators, not resolvable URLs. The linkset acknowledges this with fragment-based anchors, but the fragment-path-key convention inside the OpenAPI spec is non-standard.

Developer impact. Naive REST-style codegen against /#getBalance may construct URLs with a literal # in the path, which servers will not route; the request actually goes to POST / with the method in the body. JSON-RPC-aware tools handle this correctly, but the convention creates documentation-vs-naive-codegen friction.

Recommendation. Either use operationId alone (all operations at /, discriminated by operationId, with a narrative description of method-in-body semantics); or move the method into a non-fragment path-level identifier; or keep the current convention but add an inline description warning that the path key is a discrimination marker, not a URL-construction directive.

---

Low

F-19 — Pervasive Mintlify JSX wrappers across documentation content

Unchanged Re-check of the published text, 11 October 2026.

Category. Renderer portability Affected files. Cross-cutting across 658 mirrored documents.

Observation. The documentation uses 18+ distinct Mintlify JSX components across 6,300+ occurrences (heaviest: <Card>, <ParamField>, <Accordion>, <Note>, <CodeGroup>, <Frame>, <Warning>, <Tabs>, <Tip>, <ResponseField>, <Info>, <Steps>, <Expandable>). Mintlify renders these natively at the live site, but plain-markdown readers, mirror ingestion, and LLM context-window pastes encounter raw JSX. The <ParamField> / <ResponseField> components are heaviest at the API-reference layer, where they substitute for OpenAPI-derived parameter tables.

Recommendation. Provide a graceful-degradation render path for offline-readable mirrors, OR convention guidance for consumer-side strip-and-flatten. (A platform-level --plain-markdown export would address this generally.)

---

F-20 — _llms.txt and _llms_v2.txt are byte-identical

Could not check Re-check of the published text, 11 October 2026.

Category. Discovery surface — duplicate-output file with no apparent distinction Affected files. _llms.txt, _llms_v2.txt.

Observation. The two files are byte-identical (diff returns no difference; both 250 lines). The mirror resolved both /llms.txt and /llms-v2.txt URL candidates to the same content.

Recommendation. If llms-v2.txt is a reserved versioned-format URL, populate it with distinct v2-format content; if it is no longer reserved, remove it from any sitemap or publication so consumers do not see the duplicate.

---

F-21 — Three-format OpenAPI source-of-truth ambiguity (GitHub-hosted YAML + helius.dev-hosted JSON + rendered-doc inline YAML)

Partly fixed Re-check of the published text, 11 October 2026.

Category. Specification canonicity across formats Affected files. _api-catalog.txt (linkset), _openapi/*.json, inline YAML fragments in rendered docs.

Observation. The linkset's service-desc entries point to YAML specifications hosted on GitHub; the /openapi/<id>.json JSON files are presumably a build-output transformation; and inline YAML OpenAPI fragments are embedded in some rendered pages. Three potentially-divergent sources exist for the same surface, and cross-format byte-equivalence was not verified at this review (the GitHub-hosted YAML was not fetched). The risk is silent drift: an update applied to one format but not the others.

Recommendation. Declare a canonical source-of-truth (recommended: GitHub YAML authoritative; helius.dev JSON the published transformation; rendered-doc inline YAML a generated snippet). Add a build step verifying post-transformation equivalence at significant fields (paths / operations / response schemas).

---

Sign-off

Combined severity tally: 21 findings (0 Critical + 2 High + 16 Medium + 3 Low).

Helius's documentation set is structurally complete (657 of 659 enumerated URLs returned 200; the 2 misses are Chinese-language pages with English equivalents present), comprehensively covers 8+ product surfaces plus the legacy Enhanced API, and is best-in-class on several dimensions — particularly the rate-limit + retry-policy documentation, the component-schema $ref discipline (7 of 8 standalone specs), the canonical-host documentation banner across 658 pages, and the agent-onboarding infrastructure.

No finding rises to security-critical or integration-blocking severity. The findings concentrate on:

• OpenAPI publishing hygiene — the highest-priority item is the AWS API Gateway metadata leak in the Webhooks specification (F-2), which is unintended, reveals backend topology, and is cheap to strip via a pipeline filter.
• Cross-document host coordination — the Webhooks API is cited at conflicting hosts across four documents (F-7), preventing a developer from determining the canonical host from documentation alone.
• A documentation gap, not a security defect, at the Sender API (F-1) — the regional endpoints are plaintext HTTP by intentional, documented design for backend latency; the missing piece is an explicit confidentiality-tradeoff warning advising trusted-network-only use.
• Cross-specification consistency — title, version, OpenAPI-standard-version, path-versioning, and security-declaration inconsistencies (F-3 through F-9) that are real but reducible by reader effort.
• Schema-reuse, agent-discoverability, naming, structure, and i18n items (F-10 through F-18) that are observable doc-quality friction.
• Three low-impact items (F-19 through F-21): renderer-specific JSX wrappers, a duplicate llms.txt file, and three-format source-of-truth ambiguity.

F-2 and F-7 warrant near-term attention; the remaining consistency items are best addressed in a coordinated specification-publication revision cycle.

---

Independent documentation review. Finding IDs (F-1 through F-21) are opaque to this report.