update non-api documentation links

clients/horizonclient/main_test.go

@@ -2241,7 +2241,7 @@ var multipleOpsResponse = `{
         "selling_asset_code": "XRP",
         "selling_asset_issuer": "GBVOL67TMUQBGL4TZYNMY3ZQ5WGQYFPFD5VJRWXR72VA33VFNL225PL5",
         "offer_id": "73938565"
-      },  
+      },
       {
         "_links": {
           "self": {
@@ -2271,7 +2271,7 @@ var multipleOpsResponse = `{
         "starting_balance": "2.0000000",
         "funder": "GD7C4MQJDM3AHXKO2Z2OF7BK3FYL6QMNBGVEO4H2DHM65B7JMHD2IU2E",
         "account": "GD6LCN37TNJZW3JF2R7N5EYGQGVWRPMSGQHR6RZD4X4NATEQLP7RFAMA"
-      }          
+      }
     ]
   }
 }`
@@ -2361,7 +2361,7 @@ var transactionFailure = `{
   "type": "https://stellar.org/horizon-errors/transaction_failed",
   "title": "Transaction Failed",
   "status": 400,
-  "detail": "The transaction failed when submitted to the stellar network. The extras.result_codes field on this response contains further details.  Descriptions of each code can be found at: https://developers.stellar.org/docs/start/list-of-operations/",
+  "detail": "The transaction failed when submitted to the stellar network. The extras.result_codes field on this response contains further details.  Descriptions of each code can be found at: https://developers.stellar.org/docs/data/horizon/api-reference/aggregations/order-books/single",
   "instance": "horizon-testnet-001.prd.stellar001.internal.stellar-ops.com/4elYz2fHhC-528285",
   "extras": {
     "envelope_xdr": "AAAAAKpmDL6Z4hvZmkTBkYpHftan4ogzTaO4XTB7joLgQnYYAAAAZAAAAAAABeoyAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAD3sEVVGZGi/NoC3ta/8f/YZKMzyi9ZJpOi0H47x7IqYAAAAAAAAAAAF9eEAAAAAAAAAAAA=",

docs/reference/readme.md

@@ -7,7 +7,7 @@ The Go SDK is a set of packages for interacting with most aspects of the Stellar
 ## Horizon SDK
 
 The Horizon SDK is composed of two complementary libraries: `txnbuild` + `horizonclient`.
-The `txnbuild` ([source](https://github.com/stellar/go/tree/master/txnbuild), [docs](https://godoc.org/github.com/stellar/go/txnbuild)) package enables the construction, signing and encoding of Stellar [transactions](https://developers.stellar.org/docs/glossary/transactions/) and [operations](https://developers.stellar.org/docs/start/list-of-operations/) in Go. The `horizonclient` ([source](https://github.com/stellar/go/tree/master/clients/horizonclient), [docs](https://godoc.org/github.com/stellar/go/clients/horizonclient)) package provides a web client for interfacing with [Horizon](https://developers.stellar.org/docs/start/introduction/) server REST endpoints to retrieve ledger information, and to submit transactions built with `txnbuild`.
+The `txnbuild` ([source](https://github.com/stellar/go/tree/master/txnbuild), [docs](https://godoc.org/github.com/stellar/go/txnbuild)) package enables the construction, signing and encoding of Stellar [transactions](https://developers.stellar.org/docs/learn/glossary#transaction) and [operations](https://developers.stellar.org/docs/learn/fundamentals/transactions/list-of-operations) in Go. The `horizonclient` ([source](https://github.com/stellar/go/tree/master/clients/horizonclient), [docs](https://godoc.org/github.com/stellar/go/clients/horizonclient)) package provides a web client for interfacing with [Horizon](https://developers.stellar.org/docs/data/horizon) server REST endpoints to retrieve ledger information, and to submit transactions built with `txnbuild`.
 
 ## List of major SDK packages
 

exp/services/ledgerexporter/DEVELOPER_GUIDE.md

@@ -24,16 +24,16 @@ To achieve its goals, the ledger exporter uses the following architecture, which
 ## Data Format
 - Ledger exporter uses a compact and efficient data format called [XDR](https://developers.stellar.org/docs/learn/encyclopedia/data-format/xdr) (External Data Representation), which is a compact binary format. A Stellar Captive Core instance emits data in this format and the data structure is referred to as `LedgerCloseMeta`. The exporter bundles multiple `LedgerCloseMeta`'s into a single object using a custom XDR structure called `LedgerCloseMetaBatch` which is defined in [Stellar-exporter.x](https://github.com/stellar/go/blob/master/xdr/Stellar-exporter.x).
 
-- The metadata for the same batch is also stored alongside each exported object. Supported metadata is defined in [metadata.go](https://github.com/stellar/go/blob/master/support/datastore/metadata.go). 
+- The metadata for the same batch is also stored alongside each exported object. Supported metadata is defined in [metadata.go](https://github.com/stellar/go/blob/master/support/datastore/metadata.go).
 
 - Objects are compressed before uploading using the [zstd](http://facebook.github.io/zstd/) (zstandard) compression algorithm to optimize network usage and storage needs.
 
 ## Data Storage
-- An example implementation of `DataStore` for GCS, Google Cloud Storage. This plugin is located in the [support](https://github.com/stellar/go/tree/master/support/datastore) package. 
+- An example implementation of `DataStore` for GCS, Google Cloud Storage. This plugin is located in the [support](https://github.com/stellar/go/tree/master/support/datastore) package.
 - The ledger exporter currently implements the interface only for Google Cloud Storage (GCS). The [GCS plugin](https://github.com/stellar/go/blob/master/support/datastore/gcs_datastore.go) uses GCS-specific behaviors like conditional puts, automatic retry, metadata, and CRC checksum.
 
 ## Build, Run and Test using Docker
-The Dockerfile contains all the necessary dependencies (e.g., Stellar-core) required to run the ledger exporter. 
+The Dockerfile contains all the necessary dependencies (e.g., Stellar-core) required to run the ledger exporter.
 
 - Build: To build the Docker container, use the provided [Makefile](./Makefile). Simply run make `make docker-build` to build a new container after making any changes.
 
@@ -45,7 +45,7 @@ The Dockerfile contains all the necessary dependencies (e.g., Stellar-core) requ
 Support for different data storage types are encapsulated as 'plugins', which are implementation of `DataStore` interface in a go package. To add a data storage plugin based on a new storage type (e.g. AWS S3), follow these steps:
 
 - A data storage plugin must implement the [DataStore](https://github.com/stellar/go/blob/master/support/datastore/datastore.go) interface.
-- Add support for new datastore-specific features. Implement any datastore-specific custom logic. Different datastores have different ways of handling 
+- Add support for new datastore-specific features. Implement any datastore-specific custom logic. Different datastores have different ways of handling
   - race conditions
   - automatic retries
   - metadata storage, etc.

services/federation/README.md

@@ -1,7 +1,7 @@
 # federation server
 
 
-Go implementation of [Federation](https://developers.stellar.org/docs/glossary/federation/) protocol server. This federation server is designed to be dropped in to your existing infrastructure. It can be configured to pull the data it needs out of your existing DB.
+Go implementation of [Federation](https://developers.stellar.org/docs/learn/encyclopedia/network-configuration/federation) protocol server. This federation server is designed to be dropped in to your existing infrastructure. It can be configured to pull the data it needs out of your existing DB.
 
 ## Downloading the server
 
@@ -17,8 +17,8 @@ By default this server uses a config file named `federation.cfg` in the current
   * `dsn` - The DSN (data source name) used to connect to the database connection.  This value should be appropriate for the database type chosen.
     * for `postgres`: `postgres://user:password@host/dbname?sslmode=sslmode` ([more info](https://godoc.org/github.com/lib/pq#hdr-Connection_String_Parameters))
 * `queries`
-  * `federation` - Implementation dependent query to fetch federation results, should return either 1 or 3 columns. These columns should be labeled `id`,`memo`,`memo_type`. Memo and memo_type are optional - see [Federation](https://developers.stellar.org/docs/glossary/federation/) docs for more detail).  When executed, this query will be provided with two input parameters, the first will be the name portion of a stellar address and the second will be the domain portion of a stellar address.  For example, a request for `scott*stellar.org` would trigger a query with two input parameters, `scott` and `stellar.org` respectively. 
-  * `reverse-federation` - A SQL query to fetch reverse federation results that should return two columns, labeled `name` and `domain`.   When executed, this query will be provided with one input parameter, a [stellar account ID](https://developers.stellar.org/docs/glossary/accounts/#account-id) used to lookup the name and domain mapping.
+  * `federation` - Implementation dependent query to fetch federation results, should return either 1 or 3 columns. These columns should be labeled `id`,`memo`,`memo_type`. Memo and memo_type are optional - see [Federation](https://developers.stellar.org/docs/learn/encyclopedia/network-configuration/federation) docs for more detail).  When executed, this query will be provided with two input parameters, the first will be the name portion of a stellar address and the second will be the domain portion of a stellar address.  For example, a request for `scott*stellar.org` would trigger a query with two input parameters, `scott` and `stellar.org` respectively.
+  * `reverse-federation` - A SQL query to fetch reverse federation results that should return two columns, labeled `name` and `domain`.   When executed, this query will be provided with one input parameter, a [stellar account ID](https://developers.stellar.org/docs/learn/glossary#account-id) used to lookup the name and domain mapping.
 
     If reverse-lookup isn't supported (e.g. you have a single Stellar account for all users), leave this entry out.
 

services/horizon/README.md

@@ -1,7 +1,7 @@
 # Horizon
 [![Build Status](https://circleci.com/gh/stellar/go.svg?style=shield)](https://circleci.com/gh/stellar/go)
 
-Horizon is the client facing API server for the [Stellar ecosystem](https://developers.stellar.org/docs/start/introduction/).  It acts as the interface between [Stellar Core](https://developers.stellar.org/docs/run-core-node/) and applications that want to access the Stellar network. It allows you to submit transactions to the network, check the status of accounts, subscribe to event streams and more.
+Horizon is the client facing API server for the [Stellar ecosystem](https://developers.stellar.org).  It acts as the interface between [Stellar Core](https://developers.stellar.org/docs/validators) and applications that want to access the Stellar network. It allows you to submit transactions to the network, check the status of accounts, subscribe to event streams and more.
 
 Check out the following resources to get started:
 - [Horizon Development Guide](internal/docs/GUIDE_FOR_DEVELOPERS.md): Instructions for building and developing Horizon. Covers setup, building, testing, and contributing. Also contains some helpful notes and context for Horizon developers.
@@ -10,7 +10,7 @@ Check out the following resources to get started:
 - [Horizon SDK and API Guide](internal/docs/SDK_API_GUIDE.md): Documentation on the Horizon SDKs, APIs, resources, and examples. Useful for developers building on top of Horizon.
 
 ## Run a production server
-If you're an administrator planning to run a production instance of Horizon as part of the public Stellar network, you should check out the instructions on our public developer docs - [Run an API Server](https://developers.stellar.org/docs/run-api-server/). It covers installation, monitoring, error scenarios and more.
+If you're an administrator planning to run a production instance of Horizon as part of the public Stellar network, you should check out the instructions on our public developer docs - [Run an API Server](https://developers.stellar.org/docs/data/horizon/admin-guide). It covers installation, monitoring, error scenarios and more.
 
 ## Contributing
 As an open source project, development of Horizon is public, and you can help! We welcome new issue reports, documentation and bug fixes, and contributions that further the project roadmap. The [Development Guide](internal/docs/GUIDE_FOR_DEVELOPERS.md) will show you how to build Horizon, see what's going on behind the scenes, and set up an effective develop-test-push cycle so that you can get your work incorporated quickly.

services/horizon/cmd/root.go

@@ -21,7 +21,7 @@ var (
 			"and applications that want to access the Stellar network. It allows you to submit transactions to the " +
 			"network, check the status of accounts, subscribe to event streams and more.\n" +
 			"DEPRECATED - the use of command-line flags has been deprecated in favor of environment variables. Please" +
-			"consult our Configuring section in the developer documentation on how to use them - https://developers.stellar.org/docs/run-api-server/configuring",
+			"consult our Configuring section in the developer documentation on how to use them - https://developers.stellar.org/docs/data/horizon/admin-guide/configuring",
 		RunE: func(cmd *cobra.Command, args []string) error {
 			app, err := horizon.NewAppFromFlags(globalConfig, globalFlags)
 			if err != nil {

services/horizon/internal/docs/GUIDE_FOR_DEVELOPERS.md

@@ -17,8 +17,8 @@ git clone https://github.com/stellar/go.git
 If you want to contribute to the project, consider forking the repository and cloning the fork instead.
 
 ## Getting Started with Running Horizon
-The [start.sh](/services/horizon/docker/start.sh) script builds horizon from current source, and then runs docker-compose to start the docker containers with runtime configs for horizon, postgres, and optionally core if the optional `standalone` network parameter was included. 
-The script takes one optional parameter which configures the Stellar network used by the docker containers. If no parameter is supplied, the containers will run on the Stellar test network. Read more about the public and private networks in the [public documentation](https://developers.stellar.org/docs/fundamentals-and-concepts/testnet-and-pubnet#testnet)
+The [start.sh](/services/horizon/docker/start.sh) script builds horizon from current source, and then runs docker-compose to start the docker containers with runtime configs for horizon, postgres, and optionally core if the optional `standalone` network parameter was included.
+The script takes one optional parameter which configures the Stellar network used by the docker containers. If no parameter is supplied, the containers will run on the Stellar test network. Read more about the public and private networks in the [public documentation](https://developers.stellar.org/docs/learn/fundamentals/networks#testnet)
 
 `./services/horizon/docker/start.sh pubnet` will run the containers on the Stellar public network.
 
@@ -32,9 +32,9 @@ The following ports will be exposed:
 - Stellar-Core (If `standalone` specified): **11626**
 - Stellar-Core-Postgres (If `standalone` specified): **5641**
 
-Note that when you switch between different networks you will need to clear the Stellar Core and Stellar Horizon databases. You can wipe out the databases by running `docker-compose down --remove-orphans -v`. 
+Note that when you switch between different networks you will need to clear the Stellar Core and Stellar Horizon databases. You can wipe out the databases by running `docker-compose down --remove-orphans -v`.
 
-This script is helpful to spin up the services quickly and play around with them. However, for code development it's important to build and install everything locally 
+This script is helpful to spin up the services quickly and play around with them. However, for code development it's important to build and install everything locally
 
 ## Developing Horizon Locally
 We will now configure a development environment to run Horizon service locally without Docker.
@@ -75,7 +75,7 @@ Add a debug configuration in your IDE to attach a debugger to the local Horizon
      "args": []
  }
 ```
-If all is well, you should see ingest logs written to standard out. You can read more about configuring the different environment variables in [Configuring](https://developers.stellar.org/docs/run-api-server/configuring) section of our public documentation.
+If all is well, you should see ingest logs written to standard out. You can read more about configuring the different environment variables in [Configuring](https://developers.stellar.org/docs/data/horizon/admin-guide/configuring) section of our public documentation.
 
 ### Building Horizon Binary
 
@@ -87,7 +87,7 @@ Open a new terminal. Confirm everything worked by running `stellar-horizon --hel
 
 ### Run tests
 
-Once you have [installed stellar-core](#building-stellar-core) on your machine and have the 
+Once you have [installed stellar-core](#building-stellar-core) on your machine and have the
 [Horizon database](#database-setup) up and running, you should be able to run Horizon's unit tests:
 
 ```bash
@@ -98,7 +98,7 @@ go test ./...
 To run the integration tests, you need to set some environment variables:
 
 ```bash
-export HORIZON_INTEGRATION_TESTS_ENABLED=true 
+export HORIZON_INTEGRATION_TESTS_ENABLED=true
 export HORIZON_INTEGRATION_TESTS_CORE_MAX_SUPPORTED_PROTOCOL=21
 export HORIZON_INTEGRATION_TESTS_DOCKER_IMG=stellar/stellar-core:21
 go test -race -timeout 25m -v ./services/horizon/internal/integration/...
@@ -161,16 +161,16 @@ And finally setting the checkpoint frequency for horizon:
 export CHECKPOINT_FREQUENCY=8
 ```
 
-This modification causes the standalone network to close ledgers every 1 second and create a checkpoint once every 8 ledgers, 
-deviating from the default timing of ledger closing after 5 seconds and creating a checkpoint once every 64 ledgers. Please note that 
+This modification causes the standalone network to close ledgers every 1 second and create a checkpoint once every 8 ledgers,
+deviating from the default timing of ledger closing after 5 seconds and creating a checkpoint once every 64 ledgers. Please note that
 this customization is only applicable when running a standalone network, as it requires changes to the captive-core configuration.
 
 ## Using a specific version of Stellar Core
 
 By default, the Docker Compose file is configured to use version 21 of Protocol and Stellar Core. You can specify optional environment variables from the command shell for stating version overrides for either the docker-compose or start.sh invocations.
 ```bash
 export PROTOCOL_VERSION="21"
-export CORE_IMAGE="stellar/stellar-core:21" 
+export CORE_IMAGE="stellar/stellar-core:21"
 export STELLAR_CORE_VERSION="21.0.0-1872.c6f474133.focal"
 ```
 

services/horizon/internal/flags.go

@@ -986,7 +986,7 @@ func ApplyFlags(config *Config, flags support.ConfigOptions, options ApplyOption
 	flagsPassedByUser := flags.GetCommandLineFlagsPassedByUser()
 	if len(flagsPassedByUser) > 0 {
 		result := fmt.Sprintf("DEPRECATED - the use of command-line flags: [%s], has been deprecated in favor of environment variables. "+
-			"Please consult our Configuring section in the developer documentation on how to use them - https://developers.stellar.org/docs/run-api-server/configuring", "--"+strings.Join(flagsPassedByUser, ",--"))
+			"Please consult our Configuring section in the developer documentation on how to use them - https://developers.stellar.org/docs/data/horizon/admin-guide/overview/configuring", "--"+strings.Join(flagsPassedByUser, ",--"))
 		stdLog.Println(result)
 	}
 

services/horizon/internal/integration/parameters_test.go

@@ -496,7 +496,7 @@ func TestDeprecatedOutputs(t *testing.T) {
 		assert.Contains(t, string(outputBytes), "DEPRECATED - the use of command-line flags: "+
 			"[--disable-tx-sub], has been deprecated in favor of environment variables. Please consult our "+
 			"Configuring section in the developer documentation on how to use them - "+
-			"https://developers.stellar.org/docs/run-api-server/configuring")
+			"https://developers.stellar.org/docs/data/horizon/admin-guide/configuring")
 	})
 	t.Run("deprecated output for --captive-core-use-db", func(t *testing.T) {
 		originalStderr := os.Stderr