Rafiki

Rafiki exposes two distinct GraphQL APIs for administrative tasks. Unlike REST APIs that use endpoints, these are organized by types and fields.

1. Backend Admin API: Used for comprehensive instance management. This includes:

   • Managing peering relationships and assets.
   • Managing wallet addresses and their associated public keys.
   • Liquidity management (deposits and withdrawals).
   • Managing Open Payments resources (payments and quotes).
   • Note: The Rafiki Admin application is a frontend interface that interacts directly with this API.

2. Auth Admin API: Used for managing grants. This includes:

   • Retrieving grant information (status, state, related payment details, and grantee wallet address).
   • Revoking grants.

The backend service is the primary component of Rafiki responsible for business logic and external communication. Its core responsibilities include:

• Open Payments APIs: Exposing endpoints for public clients to initiate payments and look up information.
• Interledger Connector: Exposing an ILP connector to send and receive STREAM packets with peers.
• Account & Liquidity Management: Enabling management of accounts and tracking liquidity.
• GraphQL Backend Admin API: Providing an internal API for service operators to manage accounts, liquidity, and app settings (such as peering relationships).

Once logged in and API credentials are configured, the left-hand navigation menu provides access to the following management modules:

• Tenants: Manage tenant resources.
• Assets: Manage assets.
• Peers: Manage peers.
• Wallet addresses: Manage wallet addresses.
• Webhook events: Monitor webhook events.
• Payments: Manage and view payments.
• Account settings: Manage your own user profile and security settings.

Rafiki is an open-source solution designed for Account Servicing Entities (ASEs) to enable Interledger functionality on user accounts. You can explore the following key areas to get started:

• Playground: Test Rafiki by running two mock ASEs that automatically peer with one another.
• Integration Requirements: Review the necessary requirements for deploying Rafiki to a production environment.
• Backend API: Access the Backend GraphQL schema to understand the available data and operations.
• Auth API: Access the Auth GraphQL schema to understand authorization and authentication operations.

Rafiki implements the Open Payments standard, which allows third-party clients to securely retrieve account information and initiate payments from a customer's account with their explicit consent.

This standard provides a uniform way to manage resources and grants for:

• Incoming payments
• Quotes
• Outgoing payments

By following this standard, Rafiki enables third-party applications (like budgeting tools) to communicate with any account servicing entity that implements Open Payments, using a consistent set of APIs.

A payment pointer is a standardized identifier for a payment account that supports Interledger (ILP) payments. It must resolve to an HTTPS URL that serves as a Simple Payment Setup Protocol (SPSP) endpoint. This endpoint allows for the sending and receiving of ILP packets.

Payment pointers can be represented using the $ shorthand (e.g., $wallet.example.com/alice resolves to https://wallet.example.com/alice/).

In Rafiki, every customer account is assigned a payment pointer. Because Rafiki supports both Interledger and Open Payments, these pointers also function as wallet addresses.

The auth service is a reference implementation of an Open Payments authorization server. It allows for per-tenant management of authentication and authorization.

Key responsibilities include:

• Authorizing client requests (e.g., third-party apps) to create payments and quotes on the backend.
• Relaying interaction information to the client and recording responses.
• Issuing access tokens that define access rights and communicating with resource servers to validate those rights.

In Rafiki, a tenant represents an isolated environment for an Account Servicing Entity (ASE). Each tenant maintains its own set of resources (assets, peers, wallet addresses) and configuration settings. This architecture allows multiple ASEs to share a single Rafiki instance while ensuring data isolation and security.

Tenants can be managed via the Backend Admin API (for operators) or the Rafiki Admin app (user-friendly interface).