Integrate the Web3Signer REST API spec.

[bgravenorst]

Updates:

• Sync OpenAPI specs from the Web3Signer repo (ETH1 + ETH2) into src/openapi-specs/.
• Normalize OpenAPI servers to "" and http://localhost:9000 to prevent //path display issues.
• Bundle specs using pinned @redocly/cli@2.12.6 into src/openapi-specs/*-bundled.yaml.
• Clean and regenerate REST API docs on every sync so docs/reference/api/** is always fresh.
• Validate generated API docs on PRs by regenerating and failing if docs/reference/api/** isn’t committed.
• Remove generated .info.mdx “intro” pages after generation so they aren’t served.
• Update sync workflow to diff only `docs/reference/api/**.
• Add protocol-pliny as team reviewers on the automated sync PRs.

Preview: https://doc-web3signer-git-fork-bgravenorst-doc-339-consensys-ddffed67.vercel.app/development/reference/api/eth2/healthcheck

[vercel]

@bgravenorst is attempting to deploy a commit to the Consensys Team on Vercel.

A member of the Team first needs to authorize it.

[github-actions]

Thank you for your submission, we really appreciate it. Like many open-source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution. You can sign the CLA by just posting a Pull Request Comment same as the below format.

---

I have read the CLA Document and I hereby sign the CLA

---

_{You can retrigger this bot by commenting recheck in this Pull Request. Posted by the CLA Assistant Lite bot.}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Review	Updated (UTC)
doc-web3signer	Ready	Preview, Comment	Dec 16, 2025 2:04am

[m4sterbunny]

Suggested change

	Web3Signer supports REST and [JSON-RPC APIs](../reference/api/json-rpc.md) to sign consensus layer and execution layer payloads
	Web3Signer supports [REST](../reference/api/rest.md) and [JSON-RPC APIs](../reference/api/json-rpc.md) to sign consensus layer and execution layer payloads

[m4sterbunny]

As a (lazy) user, when I jump into an API reference I expect to see the classic items -- how to authenticate, what the rate limits are. Given this is local service none of that applies, but the security expectations are similar, so I would recommend that the reference section would still be a good location to provide context on how the service is protected.

Consider an index page for the APIs that links user back into the docs to reinforce the security mechanisms. Something like:

Web3Signer provides two API surfaces:

• [HTTP REST API](link) (used for key management, metadata, health checks, and similar operations)
• [Ethereum JSON-RPC Signing API](link) (for signing operations such as eth_sign and eth_sendRawTransaction)

Both APIs run on the same underlying HTTP server. Because neither API surface provides application-level authentication (such as API keys, Basic Auth, or OAuth), the following network-level protections are recommended:

• [TLS encryption](link) for all API communication
• [Host allowlist](link) to restrict which hosts may connect to Web3Signer
• Firewalling and use of private interfaces to limit network exposure