diff --git a/docs/fdc/attestation-types/json-api.mdx b/docs/fdc/attestation-types/json-api.mdx
index 2d526ba4..8b7f0dc2 100644
--- a/docs/fdc/attestation-types/json-api.mdx
+++ b/docs/fdc/attestation-types/json-api.mdx
@@ -9,7 +9,7 @@ unlisted: true
 :::danger
 Since May 2025 this spec is considered deprecated.
 The `JsonApi` attestation type has been update to a new version, `Web2Json`.
-You can find the updated version of this spec [here](/fdc/attestation-types/web-2-json).
+You can find the updated version of this spec [here](/fdc/attestation-types/web2-json).
 :::
 
 Data retrieval from **Web2 JSON APIs** with JQ transformations. This attestation type allows smart contracts to access and process external JSON data in a verifiable way.
diff --git a/docs/fdc/attestation-types/web-2-json.mdx b/docs/fdc/attestation-types/web2-json.mdx
similarity index 100%
rename from docs/fdc/attestation-types/web-2-json.mdx
rename to docs/fdc/attestation-types/web2-json.mdx
diff --git a/docs/fdc/guides/foundry/address-validity.mdx b/docs/fdc/guides/foundry/01-address-validity.mdx
similarity index 99%
rename from docs/fdc/guides/foundry/address-validity.mdx
rename to docs/fdc/guides/foundry/01-address-validity.mdx
index 6fa33466..73e9badc 100644
--- a/docs/fdc/guides/foundry/address-validity.mdx
+++ b/docs/fdc/guides/foundry/01-address-validity.mdx
@@ -1,10 +1,11 @@
 ---
-title: Address Validity
+title: AddressValidity
+slug: address-validity
 authors: [nikerzetic, filipkoprivec]
 description: Check the validity of a Bitcoin, Dogecoin, or XRPL address.
 tags: [intermediate, ethereum, fdc, foundry]
 keywords: [ethereum, flare-data-connector, evm, flare-network]
-sidebar_position: 3
+sidebar_position: 1
 unlisted: false
 ---
 
diff --git a/docs/fdc/guides/foundry/evm-transaction.mdx b/docs/fdc/guides/foundry/02-evm-transaction.mdx
similarity index 99%
rename from docs/fdc/guides/foundry/evm-transaction.mdx
rename to docs/fdc/guides/foundry/02-evm-transaction.mdx
index 4c98659d..3e6ee331 100644
--- a/docs/fdc/guides/foundry/evm-transaction.mdx
+++ b/docs/fdc/guides/foundry/02-evm-transaction.mdx
@@ -1,10 +1,11 @@
 ---
-title: EVM Transaction
+title: EVMTransaction
+slug: evm-transaction
 authors: [nikerzetic, filipkoprivec]
 description: Retrieve the transaction data from Ethereum, Flare, or Songbird.
 tags: [intermediate, ethereum, fdc, foundry]
 keywords: [ethereum, flare-data-connector, evm, flare-network]
-sidebar_position: 6
+sidebar_position: 1
 unlisted: false
 ---
 
diff --git a/docs/fdc/guides/foundry/payment.mdx b/docs/fdc/guides/foundry/03-payment.mdx
similarity index 99%
rename from docs/fdc/guides/foundry/payment.mdx
rename to docs/fdc/guides/foundry/03-payment.mdx
index a962757a..4ed1a174 100644
--- a/docs/fdc/guides/foundry/payment.mdx
+++ b/docs/fdc/guides/foundry/03-payment.mdx
@@ -1,10 +1,11 @@
 ---
 title: Payment
+slug: payment
 authors: [nikerzetic, filipkoprivec]
 description: Retrieve a Payment transaction data from Bitcoin, Dogecoin, or XRPL.
 tags: [intermediate, ethereum, fdc, foundry]
 keywords: [ethereum, flare-data-connector, evm, flare-network]
-sidebar_position: 8
+sidebar_position: 1
 unlisted: false
 ---
 
diff --git a/docs/fdc/guides/foundry/web-2-json.mdx b/docs/fdc/guides/foundry/04-web2-json.mdx
similarity index 99%
rename from docs/fdc/guides/foundry/web-2-json.mdx
rename to docs/fdc/guides/foundry/04-web2-json.mdx
index 3223a079..80131dd9 100644
--- a/docs/fdc/guides/foundry/web-2-json.mdx
+++ b/docs/fdc/guides/foundry/04-web2-json.mdx
@@ -1,16 +1,17 @@
 ---
 title: Web2Json
+slug: web2-json
 authors: [nikerzetic, filipkoprivec]
 description: Retrieve arbitrary Web2 data.
 tags: [intermediate, ethereum, fdc, foundry]
 keywords: [ethereum, flare-data-connector, evm, flare-network]
-sidebar_position: 8
+sidebar_position: 1
 ---
 
 import AvailableTestnet from "../_available_testnet.mdx";
 
 The `Web2Json` attestation type enables data collection from an arbitrary Web2 source.
-You can learn more about it in the official [specification repo](/fdc/attestation-types/web-2-json).
+You can learn more about it in the official [specification repo](/fdc/attestation-types/web2-json).
 
 <AvailableTestnet />
 
diff --git a/docs/fdc/guides/foundry/proof-of-reserves.mdx b/docs/fdc/guides/foundry/05-proof-of-reserves.mdx
similarity index 98%
rename from docs/fdc/guides/foundry/proof-of-reserves.mdx
rename to docs/fdc/guides/foundry/05-proof-of-reserves.mdx
index 9cff9776..334c07f8 100644
--- a/docs/fdc/guides/foundry/proof-of-reserves.mdx
+++ b/docs/fdc/guides/foundry/05-proof-of-reserves.mdx
@@ -13,13 +13,13 @@ keywords:
     proof-of-reserves,
     web2json,
   ]
-sidebar_position: 12
+sidebar_position: 1
 ---
 
 import AvailableTestnet from "../_available_testnet.mdx";
 
 This is a guide on how to build a simple dApp using the [Flare Data Connector](/fdc/overview).
-It demonstrates how multiple attestation types, namely the [EVMTransaction](/fdc/attestation-types/evm-transaction) and [Web2Json](/fdc/attestation-types/web-2-json), can be combined within the same app.
+It demonstrates how multiple attestation types, namely the [EVMTransaction](/fdc/attestation-types/evm-transaction) and [Web2Json](/fdc/attestation-types/web2-json), can be combined within the same app.
 
 The app that we will be building is called `proofOfReserves`, which enables onchain verification that a stablecoin's circulating supply is backed by sufficient offchain reserves.
 We will first describe what issue the app is addressing, and then provide a detailed walkthrough through its source code.
@@ -39,7 +39,7 @@ Implementing this verification system presents three technical challenges:
 2. **Reading onchain state**: We need to access the total token supply data from various blockchain networks.
 3. **Cross-chain data collection**: We need to aggregate token supply information across multiple chains.
 
-The [Flare Data Connector (FDC)](/fdc/overview) provides solutions for both accessing Web2 APIs through the [Web2Json](/fdc/attestation-types/web-2-json) attestation type and collecting cross-chain data via the [EVMTransaction](/fdc/attestation-types/evm-transaction) attestation type.
+The [Flare Data Connector (FDC)](/fdc/overview) provides solutions for both accessing Web2 APIs through the [Web2Json](/fdc/attestation-types/web2-json) attestation type and collecting cross-chain data via the [EVMTransaction](/fdc/attestation-types/evm-transaction) attestation type.
 For reading onchain state, we deploy a dedicated contract that reads the token supply and emits this data as an event.
 
 This guide will walk through all the components needed to build the complete `proofOfReserves` verification system.
diff --git a/docs/fdc/guides/foundry/weather-insurance.mdx b/docs/fdc/guides/foundry/06-weather-insurance.mdx
similarity index 98%
rename from docs/fdc/guides/foundry/weather-insurance.mdx
rename to docs/fdc/guides/foundry/06-weather-insurance.mdx
index 1b679016..08acc507 100644
--- a/docs/fdc/guides/foundry/weather-insurance.mdx
+++ b/docs/fdc/guides/foundry/06-weather-insurance.mdx
@@ -15,12 +15,12 @@ keywords:
     insurance,
     oracle,
   ]
-sidebar_position: 14
+sidebar_position: 1
 ---
 
 import AvailableTestnet from "../_available_testnet.mdx";
 
-In this guide, we will examine an example of a simple insurance dApp that uses the FDC's [Web2Json](/fdc/guides/hardhat/web-2-json) attestation type.
+In this guide, we will examine an example of a simple insurance dApp that uses the FDC's [Web2Json](/fdc/guides/hardhat/web2-json) attestation type.
 The dApp will allow users to create insurance policies for temperatures at specific coordinates falling below a specified threshold.
 Other users will be able to claim those policies, and the policies will be settled automatically by the contract.
 
@@ -63,7 +63,7 @@ With that we can now focus on the technical aspects of the procedure described a
 
 The contract that we will define will be called `MinTempAgency`.
 This name coincides with the field name in the response on a call to the [OpenWeatherMap API](https://openweathermap.org/api), which we will be using to acquire weather data.
-We will use the [Flare Data Connector](/fdc/overview) to collect the weather data so, in keeping with the [Web2Json guide](/fdc/guides/hardhat/web-2-json), we start by defining a `DataTransportObject` which will determine how the FDC should encode the data.
+We will use the [Flare Data Connector](/fdc/overview) to collect the weather data so, in keeping with the [Web2Json guide](/fdc/guides/hardhat/web2-json), we start by defining a `DataTransportObject` which will determine how the FDC should encode the data.
 
 ```solidity title="src/weatherInsurance/MinTempAgency.sol"
 struct DataTransportObject {
@@ -281,7 +281,7 @@ function resolvePolicy(uint256 id, IWeb2Json.Proof calldata proof) public {
 }
 ```
 
-The `IWeb2Json.Proof` is validated as demonstrated in the [Web2Json guide](/fdc/guides/hardhat/web-2-json).
+The `IWeb2Json.Proof` is validated as demonstrated in the [Web2Json guide](/fdc/guides/hardhat/web2-json).
 
 ```solidity title="src/weatherInsurance/MinTempAgency.sol"
 function isWeb2JsonProofValid(IWeb2Json.Proof calldata _proof) private view returns (bool) {
@@ -454,7 +454,7 @@ contract ClaimPolicy is Script {
 forge script script/MinTemp.s.sol:ClaimPolicy --rpc-url $COSTON2_RPC_URL --broadcast --sig "run(uint256)" <POLICY_ID>
 ```
 
-The script for resolving a policy is slightly more complicated. It involves making a Web2Json attestation request to the FDC and providing the returned proof to the `MinTempAgency` contract. To learn more about the Web2Json attestation request look at the [related guide](/fdc/guides/hardhat/web-2-json), or its [spec](/fdc/attestation-types/web-2-json).
+The script for resolving a policy is slightly more complicated. It involves making a Web2Json attestation request to the FDC and providing the returned proof to the `MinTempAgency` contract. To learn more about the Web2Json attestation request look at the [related guide](/fdc/guides/hardhat/web2-json), or its [spec](/fdc/attestation-types/web2-json).
 
 The URL we will be submitting to the FDC is the one already mentioned above. We prepare the URL using a helper function in our script, dividing the coordinates by 10<sup>6</sup> to return them to their original value.
 
diff --git a/docs/fdc/guides/foundry/web-2-json-for-custom-api.mdx b/docs/fdc/guides/foundry/07-web2-json-for-custom-api.mdx
similarity index 96%
rename from docs/fdc/guides/foundry/web-2-json-for-custom-api.mdx
rename to docs/fdc/guides/foundry/07-web2-json-for-custom-api.mdx
index a20b418d..3f038e46 100644
--- a/docs/fdc/guides/foundry/web-2-json-for-custom-api.mdx
+++ b/docs/fdc/guides/foundry/07-web2-json-for-custom-api.mdx
@@ -1,15 +1,16 @@
 ---
 title: Web2Json for Custom API
+slug: web2-json-for-custom-api
 authors: [nikerzetic, filipkoprivec]
 description: Retrieve arbitrary Web2 data.
 tags: [intermediate, ethereum, fdc, foundry]
 keywords: [ethereum, flare-data-connector, evm, flare-network]
-sidebar_position: 12
+sidebar_position: 1
 ---
 
 import AvailableTestnet from "../_available_testnet.mdx";
 
-The [Web2Json guide](/fdc/guides/foundry/web-2-json) demonstrates how the Flare Data Connector can be used to fetch Web2 and store it on the chain.
+The [Web2Json guide](/fdc/guides/foundry/web2-json) demonstrates how the Flare Data Connector can be used to fetch Web2 and store it on the chain.
 The code for this and other examples is available within the [Flare Foundry starter](https://github.com/flare-foundation/flare-foundry-starter) repository.
 In this guide, we will see how the `Web2Json` example script within the Flare Foundry starter can be modified to work with custom data and custom contracts.
 That way, the example code can serve as the base building block for a custom project.
diff --git a/docs/fdc/guides/foundry/cross-chain-payment.mdx b/docs/fdc/guides/foundry/08-cross-chain-payment.mdx
similarity index 99%
rename from docs/fdc/guides/foundry/cross-chain-payment.mdx
rename to docs/fdc/guides/foundry/08-cross-chain-payment.mdx
index 5f628fb6..5ea03d75 100644
--- a/docs/fdc/guides/foundry/cross-chain-payment.mdx
+++ b/docs/fdc/guides/foundry/08-cross-chain-payment.mdx
@@ -1,10 +1,11 @@
 ---
 title: Cross-Chain Payment
+slug: cross-chain-payment
 authors: [anthonyamadia]
 description: Use an EVMTransaction proof to verify a payment on another chain and mint an NFT.
 tags: [fdc, foundry]
 keywords: [ethereum, flare-data-connector, evm, cross-chain, payment]
-sidebar_position: 9
+sidebar_position: 1
 ---
 
 import AvailableTestnet from "../_available_testnet.mdx";
diff --git a/docs/fdc/guides/foundry/cross-chain-fdc.mdx b/docs/fdc/guides/foundry/09-cross-chain-fdc.mdx
similarity index 98%
rename from docs/fdc/guides/foundry/cross-chain-fdc.mdx
rename to docs/fdc/guides/foundry/09-cross-chain-fdc.mdx
index 91711029..c72b727f 100644
--- a/docs/fdc/guides/foundry/cross-chain-fdc.mdx
+++ b/docs/fdc/guides/foundry/09-cross-chain-fdc.mdx
@@ -6,13 +6,13 @@ description: Use the FDC data on a non-Flare, like the XRPL EVM Sidechain.
 tags: [fdc, foundry]
 keywords:
   [ethereum, flare-data-connector, evm, cross-chain, web2json, relay, xrpl]
-sidebar_position: 11
+sidebar_position: 1
 ---
 
 import AvailableTestnet from "../_available_testnet.mdx";
 
 This guide demonstrates a powerful cross-chain workflow using the Flare Data Connector (FDC).
-We will fetch data from a public Web2 API using the [Web2Json](/fdc/attestation-types/web-2-json) attestation type on a Flare network (Coston2) and then use the resulting proof to trigger a state change on a different EVM-compatible blockchain, the XRPL EVM Sidechain Testnet.
+We will fetch data from a public Web2 API using the [Web2Json](/fdc/attestation-types/web2-json) attestation type on a Flare network (Coston2) and then use the resulting proof to trigger a state change on a different EVM-compatible blockchain, the XRPL EVM Sidechain Testnet.
 
 The key to this cross-chain interaction is the `Relay` contract.
 For a non-Flare chain to verify FDC proofs, the Merkle root of each finalized voting round on Flare must be transmitted to the target chain.
diff --git a/docs/fdc/guides/foundry/json-api.mdx b/docs/fdc/guides/foundry/json-api.mdx
index f4cd7f88..236d1107 100644
--- a/docs/fdc/guides/foundry/json-api.mdx
+++ b/docs/fdc/guides/foundry/json-api.mdx
@@ -12,7 +12,7 @@ unlisted: true
 
 Since May 2025 this guide is considered deprecated.
 The `JsonApi` attestation type has been update to a new version, `Web2Json`.
-You can find the updated version of this guide [here](/fdc/guides/foundry/web-2-json).
+You can find the updated version of this guide [here](/fdc/guides/foundry/web2-json).
 
 :::
 
diff --git a/docs/fdc/guides/hardhat/address-validity.mdx b/docs/fdc/guides/hardhat/01-address-validity.mdx
similarity index 99%
rename from docs/fdc/guides/hardhat/address-validity.mdx
rename to docs/fdc/guides/hardhat/01-address-validity.mdx
index a5ec8626..98474ac8 100644
--- a/docs/fdc/guides/hardhat/address-validity.mdx
+++ b/docs/fdc/guides/hardhat/01-address-validity.mdx
@@ -1,10 +1,11 @@
 ---
-title: Address Validity
+title: AddressValidity
+slug: address-validity
 authors: [nikerzetic, filipkoprivec]
 description: Check the validity of a Bitcoin, Dogecoin, or XRPL address.
 tags: [intermediate, ethereum, fdc, hardhat]
 keywords: [ethereum, flare-data-connector, evm, flare-network]
-sidebar_position: 3
+sidebar_position: 1
 unlisted: false
 ---
 
diff --git a/docs/fdc/guides/hardhat/evm-transaction.mdx b/docs/fdc/guides/hardhat/02-evm-transaction.mdx
similarity index 99%
rename from docs/fdc/guides/hardhat/evm-transaction.mdx
rename to docs/fdc/guides/hardhat/02-evm-transaction.mdx
index e3d50182..52eed384 100644
--- a/docs/fdc/guides/hardhat/evm-transaction.mdx
+++ b/docs/fdc/guides/hardhat/02-evm-transaction.mdx
@@ -1,10 +1,11 @@
 ---
-title: EVM Transaction
+title: EVMTransaction
+slug: evm-transaction
 authors: [nikerzetic, filipkoprivec]
 description: Retrieve the transaction data from Ethereum, Flare, or Songbird.
 tags: [intermediate, ethereum, fdc, foundry]
 keywords: [ethereum, flare-data-connector, evm, flare-network]
-sidebar_position: 6
+sidebar_position: 1
 unlisted: false
 ---
 
diff --git a/docs/fdc/guides/hardhat/payment.mdx b/docs/fdc/guides/hardhat/03-payment.mdx
similarity index 99%
rename from docs/fdc/guides/hardhat/payment.mdx
rename to docs/fdc/guides/hardhat/03-payment.mdx
index 10751b72..6742b37e 100644
--- a/docs/fdc/guides/hardhat/payment.mdx
+++ b/docs/fdc/guides/hardhat/03-payment.mdx
@@ -1,10 +1,11 @@
 ---
 title: Payment
+slug: payment
 authors: [nikerzetic, filipkoprivec]
 description: Retrieve a Payment transaction data from Bitcoin, Dogecoin, or XRPL.
 tags: [intermediate, ethereum, fdc, hardhat]
 keywords: [ethereum, flare-data-connector, evm, flare-network]
-sidebar_position: 8
+sidebar_position: 1
 unlisted: false
 ---
 
diff --git a/docs/fdc/guides/hardhat/web-2-json.mdx b/docs/fdc/guides/hardhat/04-web2-json.mdx
similarity index 99%
rename from docs/fdc/guides/hardhat/web-2-json.mdx
rename to docs/fdc/guides/hardhat/04-web2-json.mdx
index 2a0df2b2..ca03c2d8 100644
--- a/docs/fdc/guides/hardhat/web-2-json.mdx
+++ b/docs/fdc/guides/hardhat/04-web2-json.mdx
@@ -1,17 +1,18 @@
 ---
 title: Web2Json
+slug: web2-json
 authors: [nikerzetic, filipkoprivec]
 description: Retrieve arbitrary Web2 data.
 tags: [intermediate, ethereum, fdc, hardhat]
 keywords: [ethereum, flare-data-connector, evm, flare-network]
-sidebar_position: 8
+sidebar_position: 1
 unlisted: false
 ---
 
 import AvailableTestnet from "../_available_testnet.mdx";
 
 The `Web2Json` attestation type enables data collection from an arbitrary Web2 source.
-You can learn more about it in the official [specification](/fdc/attestation-types/web-2-json).
+You can learn more about it in the official [specification](/fdc/attestation-types/web2-json).
 
 <AvailableTestnet />
 
@@ -89,7 +90,7 @@ In the case of `Web2Json`, `requestBody` is a JSON containing the fields:
 
 ### Reference Documentation
 
-- [Web2Json Specification](/fdc/attestation-types/web-2-json)
+- [Web2Json Specification](/fdc/attestation-types/web2-json)
 - [Verifier Interactive Docs](https://jq-verifier-test.flare.rocks/api-doc#/)
 
 ### Example Values
diff --git a/docs/fdc/guides/hardhat/proof-of-reserves.mdx b/docs/fdc/guides/hardhat/05-proof-of-reserves.mdx
similarity index 98%
rename from docs/fdc/guides/hardhat/proof-of-reserves.mdx
rename to docs/fdc/guides/hardhat/05-proof-of-reserves.mdx
index 6c99bf26..a5a49398 100644
--- a/docs/fdc/guides/hardhat/proof-of-reserves.mdx
+++ b/docs/fdc/guides/hardhat/05-proof-of-reserves.mdx
@@ -1,10 +1,11 @@
 ---
 title: Proof of Reserves
+slug: proof-of-reserves
 authors: [nikerzetic, filipkoprivec]
 description: Verifying stablecoin reserves with FDC.
 tags: [advanced, ethereum, fdc, hardhat]
 keywords: [ethereum, flare-data-connector, evm, flare-network]
-sidebar_position: 10
+sidebar_position: 1
 unlisted: false
 ---
 
@@ -12,7 +13,7 @@ import CodeBlock from "@theme/CodeBlock";
 import VerifyReservesScript from "!!raw-loader!/examples/developer-hub-javascript/fdc_verify_proof_of_reserves.ts";
 
 This is a guide on how to build a simple dApp using the [Flare Data Connector](/fdc/overview).
-It demonstrates how multiple attestation types, namely the [EVMTransaction](/fdc/attestation-types/evm-transaction) and [Web2Json](/fdc/attestation-types/web-2-json), can be combined within the same app.
+It demonstrates how multiple attestation types, namely the [EVMTransaction](/fdc/attestation-types/evm-transaction) and [Web2Json](/fdc/attestation-types/web2-json), can be combined within the same app.
 
 The app that we will be building is called `proofOfReserves`, which enables onchain verification that a stablecoin's circulating supply is backed by sufficient offchain reserves.
 We will first describe what issue the app is addressing, and then provide a detailed walkthrough through its source code.
@@ -32,7 +33,7 @@ Implementing this verification system presents three technical challenges:
 2. **Reading onchain state**: We need to access the total token supply data from various blockchain networks.
 3. **Cross-chain data collection**: We need to aggregate token supply information across multiple chains.
 
-The [Flare Data Connector (FDC)](/fdc/overview) provides solutions for both accessing Web2 APIs through the [Web2Json](/fdc/attestation-types/web-2-json) attestation type and collecting cross-chain data via the [EVMTransaction](/fdc/attestation-types/evm-transaction) attestation type.
+The [Flare Data Connector (FDC)](/fdc/overview) provides solutions for both accessing Web2 APIs through the [Web2Json](/fdc/attestation-types/web2-json) attestation type and collecting cross-chain data via the [EVMTransaction](/fdc/attestation-types/evm-transaction) attestation type.
 For reading onchain state, we deploy a dedicated contract that reads the token supply and emits this data as an event.
 
 This guide will walk through all the components needed to build the complete `proofOfReserves` verification system.
@@ -171,8 +172,8 @@ The contract defines several important components:
 
 - **Access Control**: The `updateAddress` function, protected by the `onlyOwner` modifier, provides a secure mechanism to update the registry mapping.
 
-To properly decode data from the [Web2Json](/fdc/attestation-types/web-2-json) attestation, we need to define a data structure that matches our expected format.
-Following patterns from the [Web2Json attestation type guide](/fdc/guides/hardhat/web-2-json), we create a simple `DataTransportObject` struct:
+To properly decode data from the [Web2Json](/fdc/attestation-types/web2-json) attestation, we need to define a data structure that matches our expected format.
+Following patterns from the [Web2Json attestation type guide](/fdc/guides/hardhat/web2-json), we create a simple `DataTransportObject` struct:
 
 ```solidity title="contracts/proofOfReserves/ProofOfReserves.sol"
 struct DataTransportObject {
@@ -552,7 +553,7 @@ Next, we define an `AttestationRequest` type.
 This will allow us to present the request data in a better organized format.
 Then, we prepare a list of requests, each populated with the data specified by its corresponding attestation type.
 The only two attestation types we need for this example are `IEVMTransaction` and `Web2Json`.
-For a more detailed explanation of the included fields, look at the appropriate type specification ([IEVMTransaction](/fdc/attestation-types/evm-transaction) and [Web2Json](/fdc/attestation-types/web-2-json)).
+For a more detailed explanation of the included fields, look at the appropriate type specification ([IEVMTransaction](/fdc/attestation-types/evm-transaction) and [Web2Json](/fdc/attestation-types/web2-json)).
 
 In this guide, we will be comparing the total supplies of previously deployed tokens (with an arbitrary initial supply of `666`), to the claimed reserves of a real stablecoin.
 We will obtain the dollar reserves from the API at the address: `https://api.htdigitalassets.com/alm-stablecoin-db/metrics/current_reserves_amount`.
diff --git a/docs/fdc/guides/hardhat/weather-insurance.mdx b/docs/fdc/guides/hardhat/06-weather-insurance.mdx
similarity index 97%
rename from docs/fdc/guides/hardhat/weather-insurance.mdx
rename to docs/fdc/guides/hardhat/06-weather-insurance.mdx
index 4952a66e..abdda4f9 100644
--- a/docs/fdc/guides/hardhat/weather-insurance.mdx
+++ b/docs/fdc/guides/hardhat/06-weather-insurance.mdx
@@ -1,10 +1,11 @@
 ---
 title: Weather Insurance
+slug: weather-insurance
 authors: [nikerzetic, filipkoprivec]
 description: A weather insurance dApp example.
 tags: [advanced, ethereum, fdc, hardhat]
 keywords: [ethereum, flare-data-connector, evm, flare-network]
-sidebar_position: 11
+sidebar_position: 1
 unlisted: false
 ---
 
@@ -16,7 +17,7 @@ import ExpirePolicy from "!!raw-loader!/examples/developer-hub-javascript/fdc_mi
 import ResolvePolicy from "!!raw-loader!/examples/developer-hub-javascript/fdc_min_temp_resolve_policy.ts";
 import RetireUnclaimedPolicy from "!!raw-loader!/examples/developer-hub-javascript/fdc_min_temp_retire_unclaimed_policy.ts";
 
-In this guide, we will examine an example of a simple insurance dApp that uses the FDC's [Web2Json](/fdc/guides/hardhat/web-2-json) attestation type.
+In this guide, we will examine an example of a simple insurance dApp that uses the FDC's [Web2Json](/fdc/guides/hardhat/web2-json) attestation type.
 The dApp will allow users to create insurance policies for temperatures at specific coordinates falling below a specified threshold.
 Other users will be able to claim those policies, and the policies will be settled automatically by the contract.
 
@@ -63,7 +64,7 @@ With that we can now focus on the technical aspects of the procedure described a
 
 The contract that we will define will be called `MinTempAgency`.
 This name coincides with the field name in the response on a call to the [OpenWeather](https://openweathermap.org/api) API, which we will be using to acquire weather data.
-We will use the [Flare Data Connector](/fdc/overview) to collect the weather data so, in keeping with the [Web2Json guide](/fdc/guides/hardhat/web-2-json), we start by defining a `DataTransportObject` which will determine how the FDC should encode the data.
+We will use the [Flare Data Connector](/fdc/overview) to collect the weather data so, in keeping with the [Web2Json guide](/fdc/guides/hardhat/web2-json), we start by defining a `DataTransportObject` which will determine how the FDC should encode the data.
 
 ```solidity title="contracts/weatherInsurance/MinTempAgency.sol"
 struct DataTransportObject {
@@ -286,7 +287,7 @@ A `PolicySettled` event is emitted.
     }
 ```
 
-The `IWeb2Json.Proof` is validated as demonstrated in the [Web2Json guide](/fdc/guides/hardhat/web-2-json).
+The `IWeb2Json.Proof` is validated as demonstrated in the [Web2Json guide](/fdc/guides/hardhat/web2-json).
 
 ```solidity title="contracts/weatherInsurance/MinTempAgency.sol"
     function isWeb2JsonProofValid(IWeb2Json.Proof calldata _proof) private view returns (bool) {
@@ -343,7 +344,7 @@ The `getInsurer` function allows us to query policy insurers, while the `getAllP
     }
 ```
 
-Like in the [Web2Json guide](/fdc/guides/hardhat/web-2-json), we define an `abiSignatureHack` function, that will allow us to extract the ABI signature of the `DataTransportObject` from the Hardhat-generated artifacts.
+Like in the [Web2Json guide](/fdc/guides/hardhat/web2-json), we define an `abiSignatureHack` function, that will allow us to extract the ABI signature of the `DataTransportObject` from the Hardhat-generated artifacts.
 This will be important in the next section of this guide, where we will submit a Web2Json attestation request to the FDC.
 
 ```solidity title="contracts/weatherInsurance/MinTempAgency.sol"
@@ -427,7 +428,7 @@ In this example, the policy claimed has the ID of `0`.
 
 The script for resolving a policy is slightly more complicated.
 It involves making a Web2Json attestation request to the FDC and providing the returned proof to the `MinTempAgency` contract.
-To learn more about the Web2Json attestation request look at the [related guide](/fdc/guides/hardhat/web-2-json), or its [spec](/fdc/attestation-types/web-2-json).
+To learn more about the Web2Json attestation request look at the [related guide](/fdc/guides/hardhat/web2-json), or its [spec](/fdc/attestation-types/web2-json).
 
 We prepare an attestation request using the verifier server.
 We do so by making a POST request to the appropriate endpoint;
@@ -519,7 +520,7 @@ const abiSignature = `{
        }`;
 ```
 
-The intermediate steps more or less follow the ones in the [Web2Json guide](/fdc/guides/hardhat/web-2-json).
+The intermediate steps more or less follow the ones in the [Web2Json guide](/fdc/guides/hardhat/web2-json).
 We make a POST request to the verifier server and thus prepare the attestation request.
 We submit the ABI-encoded request to the FDC, wait for the current voting round to finalize, and then collect the data from a DA Layer server.
 Finally, we decode the data to an `IWeb2Json.Response` struct and add it to an `IWeb2Json.Proof` struct, which we input into the `resolvePolicy` function, along with the policy ID, of the `MinTempAgency` at the address from the `config.ts` file.
diff --git a/docs/fdc/guides/hardhat/web-2-json-for-custom-api.mdx b/docs/fdc/guides/hardhat/07-web2-json-for-custom-api.mdx
similarity index 97%
rename from docs/fdc/guides/hardhat/web-2-json-for-custom-api.mdx
rename to docs/fdc/guides/hardhat/07-web2-json-for-custom-api.mdx
index 48712e84..2311c6e6 100644
--- a/docs/fdc/guides/hardhat/web-2-json-for-custom-api.mdx
+++ b/docs/fdc/guides/hardhat/07-web2-json-for-custom-api.mdx
@@ -1,15 +1,16 @@
 ---
 title: Web2Json for Custom API
+slug: web2-json-for-custom-api
 authors: [nikerzetic, filipkoprivec]
 description: Retrieve arbitrary Web2 data.
 tags: [intermediate, ethereum, fdc, hardhat]
 keywords: [ethereum, flare-data-connector, evm, flare-network]
-sidebar_position: 12
+sidebar_position: 1
 ---
 
 import AvailableTestnet from "../_available_testnet.mdx";
 
-The [Web2Json guide](/fdc/guides/hardhat/web-2-json) demonstrates how the Flare Data Connector can be used to fetch Web2 and store it on the chain.
+The [Web2Json guide](/fdc/guides/hardhat/web2-json) demonstrates how the Flare Data Connector can be used to fetch Web2 and store it on the chain.
 The code for this and other examples is available within the [Flare Hardhat starter](https://github.com/flare-foundation/flare-hardhat-starter) repository.
 In this guide, we will see how the `Web2Json` example script within the Flare Hardhat starter can be modified to work with custom data and custom contracts.
 That way, the example code can serve as the base building block for a custom project.
diff --git a/docs/fdc/guides/hardhat/json-api.mdx b/docs/fdc/guides/hardhat/json-api.mdx
index ee7dc572..b0866c52 100644
--- a/docs/fdc/guides/hardhat/json-api.mdx
+++ b/docs/fdc/guides/hardhat/json-api.mdx
@@ -12,7 +12,7 @@ unlisted: true
 
 Since May 2025 this guide is considered deprecated.
 The `JsonApi` attestation type has been update to a new version, `Web2Json`.
-You can find the updated version of this guide [here](/fdc/guides/hardhat/web-2-json).
+You can find the updated version of this guide [here](/fdc/guides/hardhat/web2-json).
 
 :::
 
diff --git a/docs/ftso/guides/create-custom-feed.mdx b/docs/ftso/guides/create-custom-feed.mdx
index b3ff135d..0f2b6f8b 100644
--- a/docs/ftso/guides/create-custom-feed.mdx
+++ b/docs/ftso/guides/create-custom-feed.mdx
@@ -61,7 +61,7 @@ This interface, found in the [`@flarenetwork/flare-periphery-contracts`](https:/
 
 ### Onchain contract: `PriceVerifierCustomFeed.sol`
 
-The `PriceVerifierCustomFeed.sol` contract is designed to store a historical price for a crypto asset and allow this price to be updated by verifying a proof from the [Web2Json](/fdc/attestation-types/web-2-json) FDC attestation type.
+The `PriceVerifierCustomFeed.sol` contract is designed to store a historical price for a crypto asset and allow this price to be updated by verifying a proof from the [Web2Json](/fdc/attestation-types/web2-json) FDC attestation type.
 It then exposes this price through the `IICustomFeed` interface.
 
 #### Key components
@@ -142,7 +142,7 @@ It follows these sequential steps:
 
 1. **Deploy Contract:** The script first deploys the `PriceVerifierCustomFeed.sol` contract to the network. It constructs the unique `feedId` by combining the `0x21` prefix with a hash of the asset string (e.g., "BTC/USD-HIST").
 
-2. **Prepare Attestation Request:** It constructs a request for the FDC [Web2Json](/fdc/attestation-types/web-2-json) attestation type, specifying the target API endpoint (CoinGecko), the parameters (which coin and date), and the JQ filter to extract the exact data point (the USD price) from the JSON response.
+2. **Prepare Attestation Request:** It constructs a request for the FDC [Web2Json](/fdc/attestation-types/web2-json) attestation type, specifying the target API endpoint (CoinGecko), the parameters (which coin and date), and the JQ filter to extract the exact data point (the USD price) from the JSON response.
 
 3. **Submit Request to FDC:** The script sends this request to the FDC, which fetches the data, secures it through an attestation process, and makes a proof available.