stellar · kalepail · Aug 15, 2022 · Aug 11, 2022 · Aug 11, 2022 · Aug 11, 2022
diff --git a/docs/glossary/fee-bumps.mdx b/docs/glossary/fee-bumps.mdx
@@ -2,7 +2,7 @@
 title: Fee-Bump Transactions
 ---
 
-A fee-bump transaction enables any account to pay the fee for an existing [transaction](./transactions.mdx) without the need to re-sign the existing transaction or manage sequence numbers. They're useful if you need to increase the fee on a pre-signed transaction, or if you want to build a service that covers user fees. Like a regular transaction, these are submitted to the [`/transactions` endpoint](/api/resources/transactions/). _Unlike_ a regular transaction, however, which contains 1-100 [operations](./operations.mdx), a fee-bump transaction contains a single [transaction envelope](./transactions.mdx/#transaction-envelopes).
+A fee-bump transaction enables any account to pay the fee for an existing [transaction](./transactions.mdx) without the need to re-sign the existing transaction or manage sequence numbers. They're useful if you need to increase the fee on a pre-signed transaction, or if you want to build a service that covers user fees. Like a regular transaction, these are submitted to the [`/transactions` endpoint](https://developers.stellar.org/api/resources/transactions/). _Unlike_ a regular transaction, however, which contains 1-100 [operations](./operations.mdx), a fee-bump transaction contains a single [transaction envelope](./transactions.mdx/#transaction-envelopes).
 
 ## Fee-Bump Transaction Attributes
 

diff --git a/docs/glossary/fees.mdx b/docs/glossary/fees.mdx
@@ -37,7 +37,7 @@ When network activity is below capacity, you pay the network minimum, which is c
 
 When the number of operations submitted to a ledger exceeds network capacity (**currently 1,000 ops/ledger**), the network enters surge pricing mode, which uses market dynamics to decide which submissions are included. Essentially, submissions that offer a higher fee per operation make it onto the ledger first.
 
-If there’s a tie — in other words multiple transactions that offer the same base fee are competing for the same limited space in the ledger — the transactions are (pseudo-randomly) shuffled, and transactions at the top of the heap make the ledger. The rest of the transactions, the ones that didn’t make the cut, are pushed on to the next ledger, or discarded if they’ve been waiting for too long. If your transaction is discarded, Horizon will return a [timeout error](/api/errors/http-status-codes/horizon-specific/). For more information, see [transaction life cycle](./transactions.mdx#life-cycle-of-a-transaction).
+If there’s a tie — in other words multiple transactions that offer the same base fee are competing for the same limited space in the ledger — the transactions are (pseudo-randomly) shuffled, and transactions at the top of the heap make the ledger. The rest of the transactions, the ones that didn’t make the cut, are pushed on to the next ledger, or discarded if they’ve been waiting for too long. If your transaction is discarded, Horizon will return a [timeout error](https://developers.stellar.org/api/errors/http-status-codes/horizon-specific/). For more information, see [transaction life cycle](./transactions.mdx#life-cycle-of-a-transaction).
 
 The goal of the transaction pricing specification, which you can read in full [here](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0005.md), is to maximize network throughput while minimizing transaction fees.
 

diff --git a/docs/glossary/muxed-accounts.mdx b/docs/glossary/muxed-accounts.mdx
@@ -36,7 +36,7 @@ There are many other benefits to embedding this abstraction into the protocol:
 
 It's crucial to understand that this feature is intended to be a high-level abstraction, merely embedded into the protocol for convenience and standardization. There's no validation on IDs: **as far as the Stellar Network is concerned, all of the [supported operations][supported-ops] operate exactly as if you did _not_ used a muxed account**. For example, if you make two payments from two muxed accounts that share an underlying Stellar account (i.e. muxed accounts with the same underlying `G...` account but two different IDs), this is _exactly the same_ as that single Stellar account sending two payments, as far as the ledger is concerned.
 
-Even though only the underlying `G...` account _truly_ exists in the Stellar ledger, the [Horizon API](/api/introduction/) will make some effort to interpret and track the muxed accounts responsible for certain actions.
+Even though only the underlying `G...` account _truly_ exists in the Stellar ledger, the [Horizon API](https://developers.stellar.org/api/introduction/) will make some effort to interpret and track the muxed accounts responsible for certain actions.
 
 Muxed account support is embedded into the SDKs. This means that you may see muxed addresses appear when parsing any of the fields that support them, so you should be ready to handle them. Refer to your SDK's documentation for details; for example, [v7.0.0](https://github.com/stellar/js-stellar-base/releases/tag/v7.0.0) of the JavaScript SDK library `stellar-base` describes all of the fields and functions that relate to muxed accounts.
 

diff --git a/docs/glossary/operations.mdx b/docs/glossary/operations.mdx
@@ -42,4 +42,4 @@ For more details on this process, see the [lifecycle of a transaction](./transac
 
 For each operation, there is a matching result type. In the case of success, this result allows users to gather information about the effects of the operation. In the case of failure, it allows users to learn more about the error.
 
-There are some generic errors associated with operations. For example, any operation that creates a subentry, such as `ChangeTrust` and `ManageData`, can fail with `opTOO_MANY_SUBENTRIES`. See [operations](/api/errors/result-codes/operations/) in the API reference for more information.
+There are some generic errors associated with operations. For example, any operation that creates a subentry, such as `ChangeTrust` and `ManageData`, can fail with `opTOO_MANY_SUBENTRIES`. See [operations](https://developers.stellar.org/api/errors/result-codes/operations/) in the API reference for more information.
diff --git a/docs/glossary/transactions.mdx b/docs/glossary/transactions.mdx
@@ -114,7 +114,7 @@ To determine if a transaction is valid, many checks take place over the course o
 
 1. **Signing (Transaction Signers)**: Once the transaction is completely filled out, the transaction is formed into a transaction envelope, which contains the transaction itself and a list of signers. All the required signatures must be collected and added to the transaction envelope's list of signers. Commonly it's just the signature of the account doing the transaction, but more complicated setups can require collecting [signatures from multiple parties](./multisig.mdx).
 
-1. **Submitting (Transaction Submitter)**: After signing, the transaction must be valid and can now be submitted to the Stellar network. If the transaction is invalid, it will be immediately rejected by stellar-core based on [the validity rules of a transaction](#validity-of-a-transaction), the account's sequence number will not be incremented, and no fee will be consumed from the source account. Multiple transactions for the same account can be submitted, provided each of their sequence numbers are off by one. If they are all valid, Stellar Core will craft a transaction set with each of those transactions applied in sequence number order. Transactions are typically submitted using [Horizon](/api/introduction/), but you can also submit the transaction directly to an instance of [Stellar Core](..//run-core-node/index.mdx).
+1. **Submitting (Transaction Submitter)**: After signing, the transaction must be valid and can now be submitted to the Stellar network. If the transaction is invalid, it will be immediately rejected by stellar-core based on [the validity rules of a transaction](#validity-of-a-transaction), the account's sequence number will not be incremented, and no fee will be consumed from the source account. Multiple transactions for the same account can be submitted, provided each of their sequence numbers are off by one. If they are all valid, Stellar Core will craft a transaction set with each of those transactions applied in sequence number order. Transactions are typically submitted using [Horizon](https://developers.stellar.org/api/introduction/), but you can also submit the transaction directly to an instance of [Stellar Core](..//run-core-node/index.mdx).
 
 1. **Propagating (Validator)**: Once Stellar Core has determined that a transaction is valid, it will then propagate the transaction to all of the other servers to which it's connected. In this way, a valid transaction is flooded to the entire Stellar network.
 

diff --git a/docs/run-core-node/index.mdx b/docs/run-core-node/index.mdx
@@ -7,7 +7,7 @@ import { Alert } from "@site/src/components/Alert";
 
 Stellar is a peer-to-peer network made up of nodes, which are computers that keep a common distributed [ledger](../glossary/ledger.mdx), and that communicate to validate and add [transactions](../glossary/transactions.mdx) to it. Nodes use a program called Stellar Core — an implementation of the [Stellar Consensus Protocol](../glossary/scp.mdx) — to stay in sync as they work to agree on the validity of transaction sets and to apply them to the ledger. Generally, nodes reach consensus, apply a transaction set, and update the ledger every 3-5 seconds.
 
-You don’t need to run a node to build on Stellar: you can start developing with your [SDK of choice](../software-and-sdks/index.mdx), and use public instances of Horizon to query the ledger and submit transactions right away. In fact, the Stellar Development Foundation offers two public instances of Horizon — one for the public network and one for the testnet — which you can read more about in our [API reference docs](/api/introduction/). [Lobstr](https://horizon.stellar.lobstr.co), [Public Node](https://horizon.publicnode.org/), and [Coinqvest](https://horizon.stellar.coinqvest.com) also offer public Horizon instances.
+You don’t need to run a node to build on Stellar: you can start developing with your [SDK of choice](../software-and-sdks/index.mdx), and use public instances of Horizon to query the ledger and submit transactions right away. In fact, the Stellar Development Foundation offers two public instances of Horizon — one for the public network and one for the testnet — which you can read more about in our [API reference docs](https://developers.stellar.org/api/introduction/). [Lobstr](https://horizon.stellar.lobstr.co), [Public Node](https://horizon.publicnode.org/), and [Coinqvest](https://horizon.stellar.coinqvest.com) also offer public Horizon instances.
 
 Even if you _do_ want to run your [own instance of Horizon](../run-api-server/index.mdx), it bundles its own version of Core and manages its lifetime entirely, so there's no need to run a standalone instance.
 

diff --git a/docs/software-and-sdks/index.mdx b/docs/software-and-sdks/index.mdx
@@ -7,7 +7,7 @@ sidebar_position: 0
 
 There are two key pieces of network software: Stellar Core, which tracks and adds transaction sets to the ledger, and Horizon, an API that allows programmatic access to submit transactions and query network data. To find out more about how they work together, visit the description of the [Stellar Stack](../start/stellar-stack.mdx).
 
-You do not have to run a Stellar Core node or Horizon instance to build on Stellar: you can start developing in your language of choice by installing one of the [Stellar SDKs](#sdks) below, and interacting with a public Horizon instance. To find out more about how to interact with Horizon, check out the [API Reference](/api/introduction/) section, which chronicles every Horizon endpoint, resource, aggregation, and error.
+You do not have to run a Stellar Core node or Horizon instance to build on Stellar: you can start developing in your language of choice by installing one of the [Stellar SDKs](#sdks) below, and interacting with a public Horizon instance. To find out more about how to interact with Horizon, check out the [API Reference](https://developers.stellar.org/api/introduction/) section, which chronicles every Horizon endpoint, resource, aggregation, and error.
 
 ### Stellar Core
 

diff --git a/docs/start/introduction.mdx b/docs/start/introduction.mdx
@@ -29,7 +29,7 @@ If you're new to Stellar, you may want to start by getting a high-level understa
 
 Once you have a high-level understanding of Stellar, you can start building right away, and the subsequent sections of these docs will focus on how to do that. You don't have to run your own Stellar Core node to develop on Stellar — several organizations including the Stellar Development Foundation offer public-access API endpoints that allow you to submit transactions and query the ledger — so you can focus on building your product before committing to setting up network infrastructure.
 
-If you are new, you may want to start with the early [Tutorials](../tutorials/create-account.mdx) to familiarize yourself with some of the building blocks of Stellar. You should also investigate the [SDKs](../software-and-sdks/index.mdx) designed to make developing in your language of choice easy, and familiarize yourself with the canonical [List of Operations](../start/list-of-operations.mdx), which documents everything you can do with Stellar — along with parameters and error codes — and links to the relevant documentation for key SDKs. Finally, you may want to explore the [API Reference](/api/introduction/) documentation, which details every resource, aggregation, and error provided by Horizon, the Stellar API.
+If you are new, you may want to start with the early [Tutorials](../tutorials/create-account.mdx) to familiarize yourself with some of the building blocks of Stellar. You should also investigate the [SDKs](../software-and-sdks/index.mdx) designed to make developing in your language of choice easy, and familiarize yourself with the canonical [List of Operations](../start/list-of-operations.mdx), which documents everything you can do with Stellar — along with parameters and error codes — and links to the relevant documentation for key SDKs. Finally, you may want to explore the [API Reference](https://developers.stellar.org/api/introduction/) documentation, which details every resource, aggregation, and error provided by Horizon, the Stellar API.
 
 ## Developer Channels
 

diff --git a/docs/start/stellar-stack.mdx b/docs/start/stellar-stack.mdx
@@ -15,7 +15,7 @@ SDKs make it easy to craft code and handle network queries and transaction submi
 
 ## API: Horizon
 
-[Horizon](../run-api-server/index.mdx) is a RESTful HTTP API server that provides a straightforward way to submit transactions, check accounts, and subscribe to events. Because it’s HTTP, you can communicate with Horizon using an SDK, but you can also use your web browser, or simple command line tools like cURL. Everything there is to know about Horizon is documented in the [API Reference](/api/introduction/) section of the docs.
+[Horizon](../run-api-server/index.mdx) is a RESTful HTTP API server that provides a straightforward way to submit transactions, check accounts, and subscribe to events. Because it’s HTTP, you can communicate with Horizon using an SDK, but you can also use your web browser, or simple command line tools like cURL. Everything there is to know about Horizon is documented in the [API Reference](https://developers.stellar.org/api/introduction/) section of the docs.
 
 At the moment, Horizon requires access to Stellar Core's database to function properly — so every Horizon instance connects to a Stellar Core node — but we are increasing its independence from Stellar Core, and soon developers will be able deploy the API without having to run their own node.
 

diff --git a/docs/tutorials/follow-received-payments.mdx b/docs/tutorials/follow-received-payments.mdx
@@ -111,7 +111,7 @@ After a few seconds, the Stellar network will perform consensus, close the ledge
 
 ## Following payments using `curl`
 
-To follow new payments connected to your account you simply need to send the `Accept: text/event-stream` header to the [/payments](/api/resources/operations/object/payment/) endpoint.
+To follow new payments connected to your account you simply need to send the `Accept: text/event-stream` header to the [/payments](https://developers.stellar.org/api/resources/operations/object/payment/) endpoint.
 
 <CodeExample>
 
@@ -147,7 +147,7 @@ data: {"_links":{"effects":{"href":"/operations/713226564145153/effects/{?cursor
 
 </CodeExample>
 
-Every time you receive a new payment you will get a new row of data. Payments is not the only endpoint that supports streaming. You can also stream transactions [/transactions](/api/resources/transactions/) and operations [/operations](/api/resources/operations/).
+Every time you receive a new payment you will get a new row of data. Payments is not the only endpoint that supports streaming. You can also stream transactions [/transactions](https://developers.stellar.org/api/resources/transactions/) and operations [/operations](https://developers.stellar.org/api/resources/operations/).
 
 ## Following payments using `EventStream`