[CI] Update API docs for OpenZeppelin/openzeppelin-contracts v5.7.0-rc.0

content/contracts/5.x/account-abstraction.mdx

@@ -85,13 +85,13 @@ To build your own account, see [accounts](/contracts/5.x/accounts).
 
 The smart contract accounts are created by a Factory contract defined by the Account developer. This factory receives arbitrary bytes as `initData` and returns an `address` where the logic of the account is deployed.
 
-To build your own factory, see [account factories](/contracts/5.x/accounts#accounts_factory).
+To build your own factory, see [account factories](/contracts/5.x/accounts#accounts-factory).
 
 ### Paymaster Contract
 
 A Paymaster is an optional entity that can sponsor gas fees for Accounts, or allow them to pay for those fees in ERC-20 instead of native currency. This abstracts gas away from the user experience in the same way that computational costs of cloud servers are abstracted away from end-users.
 
-To build your own paymaster, see [paymasters](https://docs.openzeppelin.com/community-contracts/0.0.1/paymasters).
+To build your own paymaster, see [paymasters](/contracts/5.x/paymasters).
 
 ## Further notes
 

content/contracts/5.x/accounts.mdx

@@ -25,7 +25,7 @@ Since the minimum requirement of [`Account`](/contracts/5.x/api/account#Account)
 * [`SignerRSA`](/contracts/5.x/api/utils/cryptography#SignerRSA): Verifies signatures of traditional PKI systems and X.509 certificates.
 * [`SignerEIP7702`](/contracts/5.x/api/utils/cryptography#SignerEIP7702): Checks EOA signatures delegated to this signer using [EIP-7702 authorizations](https://eips.ethereum.org/EIPS/eip-7702#set-code-transaction)
 * [`SignerERC7913`](/contracts/5.x/api/utils/cryptography#SignerERC7913): Verifies generalized signatures following [ERC-7913](https://eips.ethereum.org/EIPS/eip-7913).
-* [`SignerZKEmail`](https://docs.openzeppelin.com/community-contracts/0.0.1/api/utils/cryptography#SignerZKEmail): Enables email-based authentication for smart contracts using zero-knowledge proofs of email authority signatures.
+* [`SignerZKEmail`](/community-contracts/api/utils/cryptography#SignerZKEmail): Enables email-based authentication for smart contracts using zero-knowledge proofs of email authority signatures.
 * [`MultiSignerERC7913`](/contracts/5.x/api/utils/cryptography#MultiSignerERC7913): Allows using multiple ERC-7913 signers with a threshold-based signature verification system.
 * [`MultiSignerERC7913Weighted`](/contracts/5.x/api/utils/cryptography#MultiSignerERC7913Weighted): Overrides the threshold mechanism of [`MultiSignerERC7913`](/contracts/5.x/api/utils/cryptography#MultiSignerERC7913), offering different weights per signer.
 
@@ -45,7 +45,7 @@ Account factories should be carefully implemented to ensure the account address
 
 #### Handling initialization
 
-Most smart accounts are deployed by a factory, the best practice is to create [minimal clones](/contracts/5.x/api/proxy#minimal_clones) of initializable contracts. These signer implementations provide an initializable design by default so that the factory can interact with the account to set it up right after deployment in a single transaction.
+Most smart accounts are deployed by a factory, the best practice is to create [minimal clones](/contracts/5.x/api/proxy#minimal-clones) of initializable contracts. These signer implementations provide an initializable design by default so that the factory can interact with the account to set it up right after deployment in a single transaction.
 
 ```solidity
 import {Account} from "@openzeppelin/community-contracts/account/Account.sol";
@@ -82,7 +82,7 @@ function isValidSignature(bytes32 hash, bytes calldata signature) public view ov
 ```
 
 <Callout type='warn'>
-We recommend using [ERC7739](/contracts/5.x/api/utils/cryptography#ERC7739) to avoid replayability across accounts. This defensive rehashing mechanism prevents signatures for this account from being replayed in another account controlled by the same signer. See [ERC-7739 signatures](/contracts/5.x/accounts#erc_7739_signatures).
+We recommend using [ERC7739](/contracts/5.x/api/utils/cryptography#ERC7739) to avoid replayability across accounts. This defensive rehashing mechanism prevents signatures for this account from being replayed in another account controlled by the same signer. See [ERC-7739 signatures](/contracts/5.x/accounts#erc-7739-signatures).
 </Callout>
 
 ### Batched execution
@@ -152,7 +152,7 @@ const userOpData = encodeFunctionData({
 
 ## Bundle a `UserOperation`
 
-[UserOperations](/contracts/5.x/account-abstraction#useroperation) are a powerful abstraction layer that enable more sophisticated transaction capabilities compared to traditional Ethereum transactions. To get started, you’ll need an account, which you can get by [deploying a factory](/contracts/5.x/accounts#accounts_factory) for your implementation.
+[UserOperations](/contracts/5.x/account-abstraction#useroperation) are a powerful abstraction layer that enable more sophisticated transaction capabilities compared to traditional Ethereum transactions. To get started, you’ll need an account, which you can get by [deploying a factory](/contracts/5.x/accounts#accounts-factory) for your implementation.
 
 ### Preparing a UserOp
 
@@ -356,5 +356,5 @@ Smart accounts have evolved to embrace modularity as a design principle, with po
 OpenZeppelin Contracts provides both the building blocks for creating ERC-7579-compliant modules and an [`AccountERC7579`](/contracts/5.x/api/account#AccountERC7579) implementation that supports installing and managing these modules. 
 
 <Callout>
-Learn more in our [account modules](https://docs.openzeppelin.com/community-contracts/0.0.1/account-modules) section.
+Learn more in our [account modules](/community-contracts/account-modules) section.
 </Callout>