Merge branch 'main' into anchor-704-new

.prettierignore

@@ -1,2 +1,3 @@
 # openapi generated pages
 **/*.api.mdx
+**/*.tag.mdx

ap_versioned_docs/version-2.8.4/README.mdx

@@ -0,0 +1,12 @@
+---
+title: Anchor Platform Introduction
+sidebar_position: 10
+---
+
+# Anchor Platform
+
+The Anchor Platform is a set of tools and APIs that enable developers and businesses to build their own on and off-ramp services for the Stellar network. It provides a standardized interface, including the implementation of several Stellar Ecosystem Proposals (SEPs), to make it easy for businesses to integrate with Stellar-based wallets and exchanges.
+
+The platform also includes features for managing assets, transactions, and user accounts, and supports a variety of deployment options, including using Docker or Kubernetes. Overall, the Anchor Platform aims to simplify the process of building and managing a Stellar-based financial service, allowing businesses to focus on providing value to their customers.
+
+Learn about integrating with the Anchor Platform in the [Admin Guide](./admin-guide/README.mdx) or get API information in the [API Reference](./api-reference/README.mdx).

ap_versioned_docs/version-2.8.4/admin-guide/README.mdx

@@ -0,0 +1,10 @@
+---
+title: Admin Guide
+sidebar_position: 10
+---
+
+import DocCardList from "@theme/DocCardList";
+
+All you need to know about setting up, running, and using the Anchor Platform.
+
+<DocCardList />

ap_versioned_docs/version-2.8.4/admin-guide/architecture.mdx

@@ -0,0 +1,69 @@
+---
+title: "Architecture"
+sidebar_position: 20
+---
+
+## Architecture
+
+Before starting with the Anchor Platform, let's get familiar with the architecture. This section will describe the components involved and how they interact.
+
+### Fundamental Architecture
+
+The following architectural components are required for all deployments of the Anchor Platform.
+
+[![fundamental anchor platform architecture](../assets/anchor-platform-architecture-1.png)](../assets/anchor-platform-architecture-1.png)
+
+#### Client
+
+The client is an application, such as a wallet or remittance sender, that acts on behalf of a user and makes requests to the system. Clients make requests to the SEP server component of the Anchor Platform using sets of standards called [SEPs][seps] (Stellar Ecosystem Proposals).
+
+#### SEP Server
+
+The SEP server is a client-facing server and therefore needs to be accessible from an external network. The SEP server processes user requests and manages the state of transactions they initiate. When the SEP server needs to provide information it doesn't have to the client, such as the exchange rate for an asset pair or the KYC status of a customer, it makes synchronous [callback][callback-api] requests to the business server and returns the information in a SEP-compliant format.
+
+:::note
+
+The SEP server will never store any sensitive information, such as KYC (PII), in the database.
+
+:::
+
+#### Business Server
+
+The business server is a service that you (the business) must implement to connect the Anchor Platform with your internal systems. The business server responds to callback requests sent by the SEP server, such as requests for a quote, receives events sent by event service, such as notification of a received payment to your Stellar account, and provides updates to the platform server when off-chain events occur, such as the initiation of a bank transfer to a customer.
+
+#### Platform Server
+
+The platform server is an internal component. It should be hosted in a private network and should not be accessible from the Internet. This server enables the business to fetch and update the state of transactions using its [API][platform-api].
+
+#### Database
+
+The Anchor Platform uses a PostgreSQL database to store Stellar events and entities. It is primary used to store transactions.
+
+### Complete Architecture
+
+In addition to the components described above, the Anchor Platform includes several other components that offer additional functionality. Your business can chose to which of the additional components to use, but the diagram below visualizes the architecture of the system if all components are utilized.
+
+[![complete anchor platform architecture](../assets/anchor-platform-architecture-2.png)](../assets/anchor-platform-architecture-2.png)
+
+#### Event Service
+
+The event service enables the Anchor Platform to send HTTP webhooks to registered clients and your business server when the state of transactions change, removing the need for clients and/or your business server to poll the Anchor Platform's APIs. It works by reading events from published to a Kafka topic by the other Anchor Platform components. [Read more][events] about using the event service.
+
+#### Custody Server
+
+The custody server connects to enterprise wallet providers, such as Fireblocks, to send and receive payments for transactions initiated via the Anchor Platform. This service is an alternative to the Stellar Observer for businesses who use one of the supported providers. In addition to the functionality offered by the Stellar Observer, the Custody Server can also facilitate outbound payments to client's Stellar accounts. If you also use the [events] service, payments to your accounts will trigger a HTTP callback made to your business server.
+
+If you already have an integration with your wallet provider, then this component is not required, although your business server will need to notify the Anchor Platform when a payment associated with an Anchor Platform transaction was sent to or from your Stellar accounts via the [Platform API][platform-api].
+
+Currently the only supported provider is Fireblocks.
+
+#### Stellar Observer
+
+The Stellar observer, an alternative to the custody server pictured above, monitors the Stellar blockchain using Horizon, automatically detects user payments sent to the business, and updates the corresponding transactions in the Anchor Platform's database. If you also use the [events] service, payments to your accounts will trigger a HTTP callback made to your business server.
+
+If you already have a solution for monitor payments to your Stellar accounts, such as an integration with your exchange, Horizon, or RPC, then this component is not required, although your business server will need to notify the Anchor Platform when a payment associated with an Anchor Platform transaction was made to your one of your Stellar accounts via the [Platform API][platform-api].
+
+[seps]: https://github.com/stellar/stellar-protocol/blob/master/ecosystem/README.md
+[platform-api]: ../api-reference/platform/transactions/README.mdx
+[callback-api]: ../api-reference/callbacks/README.mdx
+[events]: ./events/README.mdx

ap_versioned_docs/version-2.8.4/admin-guide/component/observer/observer.mdx

@@ -0,0 +1,36 @@
+Using the Payment Observer allows you to delegate this step to the Anchor Platform. To enable the Payment Observer, use the `--stellar-observer` flag in the command section of the [compose file](../../getting-started.mdx#configuration).
+
+The Payment Observer will track all transactions sent to the distribution account. When the transaction with the expected memo is detected in the network, the status will automatically change to `pending_anchor` and event will be the emitted (if Kafka is used).
+
+In order to update the transaction's statuses, the observer makes corresponding JSON-RPC requests to the platform. It should use the following URL.
+
+<CodeExample>
+
+```bash
+# dev.env
+PLATFORM_API_BASE_URL=http://platform-server:8085
+```
+
+</CodeExample>
+
+:::caution
+
+The Payment Observer won't validate the amounts. It's your responsibility to verify that the amount sent by the user is correct.
+
+:::
+
+:::info
+
+If you already have a system that monitors payments, make sure that the logic of the system matches the description below:
+
+First, wait for the transaction to be included in the ledger (using an SDK). This transaction must have the expected memo and destination address (distribution account). Once this transaction has been detected and verified, notify the user that the funds have been received using the [notify_onchain_funds_received](#funds-received-1) JSON-RPC request.
+
+:::
+
+:::tip
+
+The Fireblocks custody service will automatically track transactions and notify the user that the funds have been received. See the [Fireblocks custody service documentation][fireblocks] for more details.
+
+:::
+
+[fireblocks]: ../../custody-services/fireblocks/README.mdx

ap_versioned_docs/version-2.8.4/admin-guide/component/rpc/error.mdx

@@ -0,0 +1,16 @@
+<div>
+
+| Error code | Meaning |
+| :--------- | :------------------------------------------- |
+| -32600 | The JSON sent is not a valid Request object |
+| -32601 | The method does not exist / is not available |
+| -32602 | Invalid method parameter(s) |
+| -32603 | Internal JSON-RPC error |
+
+</div>
+
+:::tip
+
+We will also reference a `$transaction_id` variable. This is an identification of transaction that is being returned from the Anchor Platform on an withdrawal or deposit start request. You can obtain the transaction ID by connecting the test wallet to your local Anchor Platform instance.
+
+:::

ap_versioned_docs/version-2.8.4/admin-guide/component/rpc/request.mdx

@@ -0,0 +1,29 @@
+The Request object must contain the following attributes:
+
+<AttributeTable>
+
+- ATTRIBUTE
+ - DATA TYPE
+ - DESCRIPTION
+- jsonrpc
+ - string
+ - A String specifying the version of the JSON-RPC protocol. MUST be exactly "2.0"
+- method
+ - string
+ - A String containing the name of the method to be invoked. List of available methods you can see in [JSON-RPC Methods][json-rpc-methods]
+- params
+ - object
+ - A Structured value that holds the parameter values, corresponding to method call, to be used during the invocation of the method
+- id
+ - string
+ - An identifier established by the client. The Server will reply with the same value in the Response object
+
+</AttributeTable>
+
+:::tip
+
+It's possible to provide multiple updates in a single JSON-RPC request (by placing multiple JSON-RPC request objects). When an update is done in this way, all updates will be done sequentially.
+
+Most importantly, each JSON-RPC request is not atomic. If one update fails, all previous updates WILL be applied and all subsequent updates WILL be processed and applied as well.
+
+:::

ap_versioned_docs/version-2.8.4/admin-guide/component/rpc/response.mdx

@@ -0,0 +1,33 @@
+The Response is expressed as a single JSON Object, with the following attributes:
+
+<AttributeTable>
+
+- ATTRIBUTE
+ - DATA TYPE
+ - DESCRIPTION
+- jsonrpc
+ - string
+ - A String specifying the version of the JSON-RPC protocol. It's set to "2.0"
+- result
+ - object
+ - A Structured value that holds the updated transaction details
+- id
+ - string
+ - An identifier sent by the client
+- error
+ - object
+ - A Structured value that holds the error details
+ - id
+ - string
+ - Unique id of the transaction for which an error occurred
+ - code
+ - number
+ - A number that indicates the error type that occurred. Please see a list of [error codes](#error-codes) below
+ - message
+ - string
+ - A String providing a short description of the error
+ - data
+ - string
+ - A primitive or structured value that contains additional information about the error
+
+</AttributeTable>

ap_versioned_docs/version-2.8.4/admin-guide/component/rpc/rpc.mdx

@@ -0,0 +1,17 @@
+Before making JSON-RPC requests, let's first create a template for making a request to the Anchor Platform.
+
+<CodeExample>
+
+```bash
+# call-json-rpc.sh
+#!/usr/bin/env bash
+
+curl localhost:8085 \
+ -X POST \
+ -H 'Content-Type: application/json' \
+ --data "@$1"
+```
+
+</CodeExample>
+
+This small script will make a JSON-RPC request to the Anchor Platform hosted on the default port (8085). JSON transaction data stored in the provided file will be used as body (requests must be an array).

ap_versioned_docs/version-2.8.4/admin-guide/component/security/api_key.mdx

@@ -0,0 +1,14 @@
+To enable API key authentication, modify your `dev.env` file:
+
+<CodeExample>
+
+```bash
+# dev.env
+PLATFORM_SERVER_AUTH_TYPE=api_key
+# Will be used as API key
+SECRET_PLATFORM_API_AUTH_SECRET="your API key that business server will use"
+```
+
+</CodeExample>
+
+After it's enabled, all requests must contain a valid `X-Api-Key` header, set to the configured API key.

ap_versioned_docs/version-2.8.4/admin-guide/component/security/jwt.mdx

@@ -0,0 +1,14 @@
+To enable API key authentication, modify your `dev.env` file:
+
+<CodeExample>
+
+```bash
+# dev.env
+PLATFORM_SERVER_AUTH_TYPE=api_key
+# Will be used as API key
+SECRET_PLATFORM_API_AUTH_SECRET="your API key that business server will use"
+```
+
+</CodeExample>
+
+After it's enabled, all requests must contain a valid `X-Api-Key` header, set to the configured API key.

ap_versioned_docs/version-2.8.4/admin-guide/component/security/security.mdx

@@ -0,0 +1,11 @@
+:::caution
+
+By default, the Platform API's endpoints such as `GET /transactions` and `GET /transactions/:id` are not protected, and are accessible by anyone who has access to the server, including wallet applications.
+
+:::
+
+:::info
+
+It's recommended to keep Platform server accessible only from the private network. However, you may want to add additional layer of protection via securing the API.
+
+:::

ap_versioned_docs/version-2.8.4/admin-guide/custody-services/README.mdx

@@ -0,0 +1,10 @@
+---
+title: Custody Services
+sidebar_position: 80
+---
+
+import DocCardList from "@theme/DocCardList";
+
+Using a custody service will allow you to use an outside service to store and manage your wallets.
+
+<DocCardList />