-| Package name | Services |
-| ---------------------------------------------------- | ---------------------------------------------------------------------------------------------------- |
-| [`backend`](/integration/services/backend-service) |
diff --git a/packages/documentation/src/content/docs/integration/requirements/idp.mdx b/packages/documentation/src/content/docs/integration/requirements/idp.mdx
index 4c839264d7..73d9db77d9 100644
--- a/packages/documentation/src/content/docs/integration/requirements/idp.mdx
+++ b/packages/documentation/src/content/docs/integration/requirements/idp.mdx
@@ -44,7 +44,7 @@ Your IdP:
The purpose of an Open Payments authorization server is to grant permission to clients to access the Open Payments APIs. These APIs are used to create incoming payments, quotes, and outgoing payments against an account holder's account.
-Rafiki's [auth service](/integration/services/auth-service) provides you with a reference implementation of an Open Payments authorization server. You can use the service as an alternative to developing your own in-house service.
+Rafiki's [auth service](/integration/deployment/services/auth-service) provides you with a reference implementation of an Open Payments authorization server. You can use the service as an alternative to developing your own in-house service.
The authorization server extends an HTTP API for your IdP to use to start and finish interactions, collect authorization, get information about a grant, and communicate whether an end-user has authorized a grant. The API's [endpoints](#interaction-endpoints) are described below.
diff --git a/packages/documentation/src/content/docs/integration/requirements/peers.mdx b/packages/documentation/src/content/docs/integration/requirements/peers.mdx
new file mode 100644
index 0000000000..0e37425cda
--- /dev/null
+++ b/packages/documentation/src/content/docs/integration/requirements/peers.mdx
@@ -0,0 +1,291 @@
+---
+title: Peers
+---
+
+import { CodeBlock, LinkOut } from '@interledger/docs-design-system'
+
+To join the Interledger network and be able to send and receive payments, you must add one or more peer(s) to your Rafiki instance. Peering establishes the connections needed for your Rafiki instance to interact with another account servicing entity (ASE). The purpose of this guide is to help you set up and manage peers.
+
+While this guide focuses on the conceptual and technical steps of adding and managing peers via the Backend Admin API, the Rafiki Admin application offers the same functionality in a user-friendly interface.
+
+Refer to the [Rafiki Admin user guide](/admin/admin-user-guide#peers) for detailed instructions and examples of creating and managing peers through the application.
+
+:::tip
+Whether you are using the Backend Admin API or the Rafiki Admin application, the underlying configurations and requirements remain the same. Choose the interface that best suits your individual workflow.
+:::
+
+## Prerequisites
+
+:::note
+Peering is not required unless you want to participate in transactions with another ASE on the Interledger network. For foundational peering concepts, refer to the Peers section of [Interledger Concepts](/overview/concepts/interledger/#peers).
+:::
+
+Before adding a peer, you and the account servicing entity you intend to peer with must both:
+
+- Run an implementation of an [Interledger connector](/integration/deployment/services/backend-service#interledger-connector) (ideally Rafiki).
+- Agree on an [asset](/overview/concepts/accounting#assets) for the peering relationship. You can set up multiple peering relationships with the same peer based on different assets. At least one asset shared by you and your peer must be added to your Rafiki instance prior to setting up the peering relationship. For more information, refer to [Assets](/integration/requirements/assets/).
+- Exchange static - SPSP
- Open Payments APIs
- GraphQL Admin APIs
- STREAM endpoint
- SPSP
- Open Payments APIs
- GraphQL Admin APIs
- STREAM endpoint
+
+| Variable | Description | Required |
+| -------------------------- | --------------------------------------------------------------------------------------------------------------------------- | -------- |
+| `assetID` | The ID of the asset that you and your peer will use to ultimately settle your net obligations outside of Interledger. | Y |
+| `staticILPaddress` | Your peer’s static ILP address (the example uses `g.othergreatwallet`) | Y |
+| `name` | Your peer’s name (the example uses “The Other Great Wallet”) | Y |
+| `http.incoming.authTokens` | An array of auth tokens accepted by your Rafiki instance for authenticating incoming packets from your peer. | Y |
+| `http.outgoing.endpoint` | Your peer’s connector endpoint. By default it is on local port 0.0.0.0:3002 | Y |
+| `http.outgoing.authToken` | The auth token presented to your peer for authenticating outgoing packets from your Rafiki instance. | Y |
+| `initialLiquidity` | Initial amount of liquidity to deposit for peer. Liquidity can also be deposited using the `DepositPeerLiquidity` mutation. | N |
+
+
+
+
+
+
+```graphql
+mutation UpdatePeer($input: UpdatePeerInput!) {
+ updatePeer(input: $input) {
+ peer {
+ id
+ name
+ http {
+ outgoing {
+ authToken
+ endpoint
+ }
+ }
+ maxPacketAmount
+ liquidityThreshold
+ }
+ }
+}
+```
+
+
+
+##### Example
+
+The input object for the update operation only requires that the `id` is present. All other variables are optional. For this example we will include the required `id` variable, as well as the optional variables of the fields we wish to update. In this case, `maxPacketAmount` and `liquidityThreshold`.
+
+
+
+```json
+{
+ "input": {
+ "id": "480ef339-7842-4501-a905-923fc1339cef",
+ "maxPacketAmount": 1000,
+ "liquidityThreshold": 100
+ }
+}
+```
+
+
+
+
+
+```json
+{
+ "data": {
+ "updatePeer": {
+ "code": "200",
+ "success": true,
+ "message": "Updated ILP Peer",
+ "peer": {
+ "id": "480ef339-7842-4501-a905-923fc1339cef",
+ "name": "The Other Great Wallet",
+ "http": {
+ "outgoing": {
+ "authToken": "test",
+ "endpoint": "http://peering-test:3002"
+ }
+ },
+ "maxPacketAmount": 1000,
+ "liquidityThreshold": 100
+ }
+ }
+ }
+}
+```
+
+
+
+
+### Delete a peer
+
+How to edit a peer
+Occasionally, you may need to adjust peering configurations or address any changes communicated by the peer. Some examples include updating new endpoints or tokens, technical settings like the maximum packet amount, or peer liquidity thresholds. + +In this example we are going to update the peer we just created. Rather than change any of the peering details, we can add some optional details that we didn't include when we created the peer. We will define the `maxPacketAmount` and the `liquidityThreshold`. + +#### `updatePeer` + +
+
+| Variable | Description | Required |
+| -------------------- | ------------------------------------------------------------------------------------------------------ | -------- |
+| `id` | The ID of the peer you wish to update. | Y |
+| `maxPacketAmount` | Maximum packet size you are willing to accept from the peer. | N |
+| `liquidityThreshold` | A webhook event will notify the Account Servicing Entity if peer liquidity falls below this new value. | N |
+
+
+
+
+
+
+```graphql
+mutation DeletePeer($input: DeletePeerInput!) {
+ deletePeer(input: $input) {
+ success
+ }
+}
+```
+
+
+
+##### Example
+
+
+
+```json
+{
+ "input": {
+ "id": "480ef339-7842-4501-a905-923fc1339cef"
+ }
+}
+```
+
+
+
+
+
+```json
+{
+ "data": {
+ "deletePeer": {
+ "success": true
+ }
+ }
+}
+```
+
+
+
diff --git a/packages/documentation/src/content/docs/integration/requirements/webhook-events.mdx b/packages/documentation/src/content/docs/integration/requirements/webhook-events.mdx
index 756bb1a841..071612998c 100644
--- a/packages/documentation/src/content/docs/integration/requirements/webhook-events.mdx
+++ b/packages/documentation/src/content/docs/integration/requirements/webhook-events.mdx
@@ -24,7 +24,7 @@ Rafiki doesn't hold _user_ account balances. Instead, Rafiki keeps track of the
For Rafiki to notify you about webhook events, you must expose a webhook endpoint that listens for the events dispatched by Rafiki. These events notify your system of time-sensitive status updates, warnings, and errors so that you can react accordingly.
-When an event occurs, the [`backend`](/integration/services/backend-service) service makes a How to delete a peer
+Deleting a peer is an action that removes a peer from your Rafiki instance. There are specific rules and considerations to keep in mind before initating this irreversible operation. + +A peer can only be deleted if no payments have been made to or received from that peer. This ensures that historical payment records are preserved. If you attempt to delete a peer with payment history, the backend will throw an error, preventing the deletion. + +Deleting a peer is useful in situations where there were configuration errors when the peer was first created like an incorrect auth token or ILP address. + +:::danger +Deleting a peer is permanent and cannot be reversed. If you delete a peer in error, you must create another new peer. +::: + +#### `deletePeer` + +
+
+| Variable | Description | Required |
+| -------- | -------------------------------------- | -------- |
+| `id` | The ID of the peer you wish to delete. | Y |
+
+
+
+
diff --git a/packages/documentation/src/content/docs/overview/concepts/accounting.mdx b/packages/documentation/src/content/docs/overview/concepts/accounting.mdx
index 9ea2b75982..3fa0a247a3 100644
--- a/packages/documentation/src/content/docs/overview/concepts/accounting.mdx
+++ b/packages/documentation/src/content/docs/overview/concepts/accounting.mdx
@@ -60,7 +60,7 @@ $\frac{10000}{10^2} =100.00$ USD
TigerBeetle is a high-performance distributed financial accounting database used by Rafiki’s `backend` service to store account balance data at the ILP layer. Both liquidity and settlement accounts in Rafiki correspond to TigerBeetle credit and debit accounts, respectively. TigerBeetle only holds balance data without any additional ILP packet metadata. For detailed information on TigerBeetle, including its consensus mechanism and its limitations, visit the official TigerBeetle documentation and blog .
-You have the flexibility to choose whether to use TigerBeetle or opt for a separate Postgres database. However, TigerBeetle is recommended due to its speed, efficiency, and dedicated design for handling double ledger accounting. For more information about Tigerbeetle in a production environment, see [Running Rafiki in production](/integration/prod/helm-k8s/#tigerbeetle).
+You have the flexibility to choose whether to use TigerBeetle or opt for a separate Postgres database. However, TigerBeetle is recommended due to its speed, efficiency, and dedicated design for handling double ledger accounting. For more information about Tigerbeetle in a production environment, see [Running Rafiki in production](/integration/deployment/helm-k8s/#tigerbeetle).
## Liquidity
diff --git a/packages/documentation/src/content/docs/overview/concepts/interledger.mdx b/packages/documentation/src/content/docs/overview/concepts/interledger.mdx
index 580b32bd3d..8398fd2e7a 100644
--- a/packages/documentation/src/content/docs/overview/concepts/interledger.mdx
+++ b/packages/documentation/src/content/docs/overview/concepts/interledger.mdx
@@ -18,7 +18,7 @@ Each packet represents a conditional IOU which affects financial accounting bala
Interledger itself is a network of computers that enables sending payment messages across payment networks. Each computer on the network is called a node.
-For two nodes on the Interledger network to exchange ILP packets with one another, the two nodes must be peers. There are a number of [requirements](/admin/manage-peering) that both you and your potential peer must meet in order to form a peering relationship.
+For two nodes on the Interledger network to exchange ILP packets with one another, the two nodes must be peers. There are a number of [requirements](/integration/requirements/peers#prerequisites) that both you and your potential peer must meet in order to form a peering relationship.
Since the purpose of peering is to facilitate payments, which often involves extending lines of credit, your peer should be someone you trust. We strongly recommend you and your potential peer define your expectations and outline your agreements in a legally-binding document peering with one another.
@@ -30,7 +30,7 @@ Each node on the Interledger network can take on the role of sender, connector,
- Connector - An intermediary between a sender and receiver that forwards ILP packets. Connectors can facilitate payments to or from anyone they’re peered with.
- Receiver - The final recipient of the ILP packets and, as such, the payment.
-If the sender and receiver nodes are peers, then the payment flow is straightforward and no intermediary connector nodes are needed. However, if the sender and receiver aren’t peers, then the payment must be routed through one or more connectors. Rafiki’s [backend service](/integration/services/backend-service#interledger-connector) includes an Interledger connector for sending and receiving ILP packets.
+If the sender and receiver nodes are peers, then the payment flow is straightforward and no intermediary connector nodes are needed. However, if the sender and receiver aren’t peers, then the payment must be routed through one or more connectors. Rafiki’s [backend service](/integration/deployment/services/backend-service#interledger-connector) includes an Interledger connector for sending and receiving ILP packets.
In the image below, the sender node (A) and the receiver node (C) share a common peer (B). In payments from the sender to the receiver, node B performs the role of connector to facilitate payments between the two.
diff --git a/packages/documentation/src/content/docs/overview/concepts/open-payments.mdx b/packages/documentation/src/content/docs/overview/concepts/open-payments.mdx
index ca7c364e7c..8a5d30539f 100644
--- a/packages/documentation/src/content/docs/overview/concepts/open-payments.mdx
+++ b/packages/documentation/src/content/docs/overview/concepts/open-payments.mdx
@@ -31,8 +31,8 @@ We strongly encourage you to familiarize yourself with the Open Payments standar
## Rafiki's backend service
-Rafiki’s [`backend`](/integration/services/backend-service) service is the main service for handling business logic and external communication. The service is responsible for, among other things, exposing the endpoints of the Open Payments APIs for clients to perform account management tasks. Every request and response is validated against the Open Payments specification .
+Rafiki’s [`backend`](/integration/deployment/services/backend-service) service is the main service for handling business logic and external communication. The service is responsible for, among other things, exposing the endpoints of the Open Payments APIs for clients to perform account management tasks. Every request and response is validated against the Open Payments specification .
## Rafiki's auth service
-Rafiki’s [`auth`](/integration/services/auth-service) service is a reference implementation of an opinionated Open Payments authorization server. The authorization server is responsible for delegating authorization (via grants) to clients to use the Open Payments APIs, resolving clients’ public keys to authenticate and authorize incoming requests, and creating payments and quotes on the backend. Open Payments leverages the Grant Negotiation and Authorization Protocol (GNAP) for delegating authorization. You can learn more about the protocol by reviewing its specification .
+Rafiki’s [`auth`](/integration/deployment/services/auth-service) service is a reference implementation of an opinionated Open Payments authorization server. The authorization server is responsible for delegating authorization (via grants) to clients to use the Open Payments APIs, resolving clients’ public keys to authenticate and authorize incoming requests, and creating payments and quotes on the backend. Open Payments leverages the Grant Negotiation and Authorization Protocol (GNAP) for delegating authorization. You can learn more about the protocol by reviewing its specification .
diff --git a/packages/documentation/src/content/docs/resources/architecture.mdx b/packages/documentation/src/content/docs/resources/architecture.mdx
index 1b1f794e83..b227a013a0 100644
--- a/packages/documentation/src/content/docs/resources/architecture.mdx
+++ b/packages/documentation/src/content/docs/resources/architecture.mdx
@@ -6,9 +6,9 @@ import { LinkOut } from '@interledger/docs-design-system'
Rafiki is a collection of three services that run together. Each one can be scaled horizontally.
-- [Backend](/integration/services/backend-service) - The main service, responsible for handling business logic and external communication
-- [Auth](/integration/services/auth-service) - A reference implementation of an Open Payments authorization server, used for grant authorization and authentication
-- [Frontend](/integration/services/frontend-service) - An optional internal user interface, called the [Rafiki Admin](/admin/admin-user-guide), for you to manage your Rafiki instance
+- [Backend](/integration/deployment/services/backend-service) - The main service, responsible for handling business logic and external communication
+- [Auth](/integration/deployment/services/auth-service) - A reference implementation of an Open Payments authorization server, used for grant authorization and authentication
+- [Frontend](/integration/deployment/services/frontend-service) - An optional internal user interface, called the [Rafiki Admin](/admin/admin-user-guide), for you to manage your Rafiki instance
These services rely on a number of databases.
@@ -21,6 +21,6 @@ These services rely on a number of databases.
, used by the `backend` service for accounting balances at the ILP layer
- A Redis database used by the `backend` service as a cache to share STREAM connection details across processes
-An additional package for [token introspection](/integration/services/token-introspection) is also included with Rafiki. This is an internal package that requires no action on your part if you’re using Rafiki’s `auth` service.
+An additional package for [token introspection](/integration/deployment/services/token-introspection) is also included with Rafiki. This is an internal package that requires no action on your part if you’re using Rafiki’s `auth` service.
diff --git a/packages/frontend/app/routes/peers.$peerId.tsx b/packages/frontend/app/routes/peers.$peerId.tsx
index a59d8701c0..0458ddae16 100644
--- a/packages/frontend/app/routes/peers.$peerId.tsx
+++ b/packages/frontend/app/routes/peers.$peerId.tsx
@@ -214,7 +214,7 @@ export default function ViewPeerPage() {
List of valid tokens to accept when receiving incoming{' '}
ILP packets
{' '}
@@ -234,7 +234,7 @@ export default function ViewPeerPage() {
Valid auth token to present when sending outgoing{' '}
ILP packets
{' '}
diff --git a/packages/frontend/app/routes/peers.create.tsx b/packages/frontend/app/routes/peers.create.tsx
index c8d2cc1413..2ddb1324b4 100644
--- a/packages/frontend/app/routes/peers.create.tsx
+++ b/packages/frontend/app/routes/peers.create.tsx
@@ -149,7 +149,7 @@ export default function CreatePeerPage() {
List of valid tokens to accept when receiving incoming{' '}
ILP packets
{' '}
@@ -168,7 +168,7 @@ export default function CreatePeerPage() {
Valid auth token to present when sending outgoing{' '}
ILP packets
{' '}
diff --git a/packages/frontend/app/routes/peers.$peerId.tsx b/packages/frontend/app/routes/peers.$peerId.tsx
index a59d8701c0..0458ddae16 100644
--- a/packages/frontend/app/routes/peers.$peerId.tsx
+++ b/packages/frontend/app/routes/peers.$peerId.tsx
@@ -214,7 +214,7 @@ export default function ViewPeerPage() {
List of valid tokens to accept when receiving incoming{' '}
ILP packets
{' '}
@@ -234,7 +234,7 @@ export default function ViewPeerPage() {
Valid auth token to present when sending outgoing{' '}
ILP packets
{' '}
diff --git a/packages/frontend/app/routes/peers.create.tsx b/packages/frontend/app/routes/peers.create.tsx
index c8d2cc1413..2ddb1324b4 100644
--- a/packages/frontend/app/routes/peers.create.tsx
+++ b/packages/frontend/app/routes/peers.create.tsx
@@ -149,7 +149,7 @@ export default function CreatePeerPage() {
List of valid tokens to accept when receiving incoming{' '}
ILP packets
{' '}
@@ -168,7 +168,7 @@ export default function CreatePeerPage() {
Valid auth token to present when sending outgoing{' '}
ILP packets
{' '}