Skip to main content

StableX Complete API Reference

Use the On this page menu on the right to jump to any section.

1. API Overview

1.1 GraphQL Endpoint

1.2 Headers

1.3 Request Format


2. Authentication

Automatically detects if user is a Merchant or Staff member. Permissions: None (public) Request:
Variables:
Response (Merchant):
Response (Staff):

2.2 Merchant Login (Legacy)

Permissions: None (public) Request:
Variables:
Response:

2.3 Staff Login (Legacy)

Permissions: None (public) Request:
Variables:
Response:

2.4 Refresh Token

Get a new access token without re-entering credentials. Permissions: None (public, but requires valid refresh token) Request:
Variables:
Response:

2.5 Request Password Reset

Permissions: None (public) Request:
Variables:
Response:

2.6 Reset Password

Permissions: None (public, but requires valid token) Request:
Variables:
Response:

2.7 Get Current User (Me)

Permissions: Requires authentication Request:
Response (Merchant):
Response (Staff):

3. Merchant Operations

3.1 Create Merchant (Sign Up)

Permissions: None (public) Request:
Variables:
Response:

3.2 Update Merchant Profile

Permissions: merchant.profile.manage (Merchant only) Request:
Variables:
Response:

3.3 Merchant Account Number

Every merchant is automatically assigned a unique 16-digit account number upon creation. Format: 9891 + 12 random digits Example: 9891123456789012 Features:
  • Automatically Generated: Created when a merchant signs up
  • Unique: Enforced by database constraint
  • Immutable: Cannot be changed after creation
  • Format Validation: Checked via database constraint (^9891[0-9]{12}$)
Use Cases:
  • Merchant identification
  • Account reconciliation
  • Integration with external systems
  • Customer invoicing
Querying Account Number:
Response:

4. Staff Management

4.1 Create Staff

Permissions: staff.manage (Merchant or Manager with staff.manage permission) Request:
Variables:
Response:
Note: The merchantId parameter is optional:
  • If omitted, the merchant ID is automatically inferred from the authenticated user (works for both Merchant and Staff users)
  • If provided, it must match the authenticated user’s merchant ID (staff cannot create users for other merchants)
  • Can be passed as either a string ("1") or number (1) - both are accepted

4.2 List Staff

Permissions: staff.list Request:
Variables:
Response:

4.3 Update Staff

Permissions: staff.manage Request:
Variables:
Response:

4.4 Deactivate Staff

Permissions: staff.manage Request:
Variables:
Response:

4.5 Assign Role to Staff

Permissions: staff.manage Request:
Variables:
Response:

4.6 Get Merchant Info for Staff

Permissions: Requires authentication Request:
Variables:
Response:

5. Payment Operations

5.1 Create Payment

Permissions: payment.create Request:
Variables:
Response:

5.2 Regenerate Payment

Permissions: payment.create Request:
Variables:
Response:

Creates a shareable payment link: a pending transaction, invoice, and a unique slug. The returned url is the public checkout URL (e.g. https://your-domain.com/pay/<slug>). No authentication is required for customers to open that URL and pay. Permissions: payment.create Request:
Variables:
Response:
  • url: Public URL to share with the customer. Opening it returns checkout JSON (see 5.4).
  • slug: Unique identifier for the link (also used in url).
  • expiresInHours: Optional. If set, the link is considered expired after that many hours.

Authentication: None (public endpoint for customers). Returns JSON for the checkout UI: merchant name, amount, token, network, payment URL (for QR / Solana Pay), and transaction reference. Used when a customer opens a payment link (e.g. https://your-domain.com/pay/<slug>). Endpoint:
Example:
Response (200 OK):
  • payment_url: Use this for QR code or “Pay with Solana” / wallet deep link.
  • transaction_reference: Use with transactionStatus(reference: ...) to poll for confirmation.
Errors:
  • 404: Payment link not found, expired, or already used (transaction confirmed).

6. Transaction & Reporting

6.1 List Transactions

Permissions: transaction.view Request:
Variables:
Response:

6.2 Transaction Status

Permissions: transaction.view Request:
Variables:
Response:

6.3 Daily Summary

Permissions: report.view Request:
Variables:
Response:

6.4 Sales Summary Report

Permissions: report.view Request:
Variables:
Response:

6.5 Sales Analytics

Permissions: report.view Request:
Variables:
Response:

6.6 Sales By Hour

Permissions: report.view Request:
Response:

6.7 PDF Downloads (Invoices & Receipts)

StableX provides two types of PDF documents:
  • Invoices: For pending/unpaid transactions (blue header, red “PAYMENT PENDING” stamp)
  • Receipts: For confirmed/paid transactions (green header, green “PAID” stamp)

6.7.1 Get Invoice Info (GraphQL)

Get the download URL and QR code for an invoice PDF. Permissions: Authenticated (merchant or staff) Request:
Variables:
Response:

6.7.2 Get Receipt Info (GraphQL)

Get the download URL and QR code for a receipt PDF. Permissions: Authenticated (merchant or staff) Request:
Variables:
Response:

6.7.3 Download Invoice PDF (REST API)

Download the invoice PDF directly. Endpoint: GET /invoices/{transaction_reference}/download Authentication: Bearer token required Request:
Response: PDF file (application/pdf) Status Codes:
  • 200 OK: PDF generated successfully
  • 404 Not Found: Transaction not found
  • 401 Unauthorized: Invalid or missing token
  • 500 Internal Server Error: PDF generation failed

6.7.4 Download Receipt PDF (REST API)

Download the receipt PDF directly (only for confirmed transactions). Endpoint: GET /receipts/{transaction_reference}/download Authentication: Bearer token required Request:
Response: PDF file (application/pdf) Status Codes:
  • 200 OK: PDF generated successfully
  • 404 Not Found: Transaction not found or not confirmed
  • 401 Unauthorized: Invalid or missing token
  • 500 Internal Server Error: PDF generation failed
Note: Receipts can only be downloaded for transactions with status confirmed. For pending transactions, use the invoice endpoint instead.

6.7.5 Invoice Query with Transaction Reference

When querying invoices, include the transaction relationship to get the reference needed for PDF downloads. Invoices can be in lifecycle states: draft, sent, pending, paid, overdue, or void. Draft and sent invoices may have transaction_id: null until the customer pays. Request:
Response:
Usage: For paid (or sent) invoices with a transaction, use transaction.reference to construct the download URL:

6.8 Invoice Lifecycle (Draft, Send, Remind)

Invoices support a full lifecycle: create as draft, send to the customer (email + payment link), then paid when the customer pays. Optional overdue status and reminders are supported. Invoice statuses: draft | sent | pending | paid | overdue | void
  • draft: Created without a transaction; can be updated.
  • sent: Payment link created and (optionally) email sent; transaction_id and sent_at set.
  • pending: Legacy: invoice tied to a transaction not yet confirmed.
  • paid: Payment confirmed; payment_date set.
  • overdue: due_date has passed and status was sent.
  • void: Cancelled.

6.8.1 Create Invoice (Draft)

Create an invoice in draft state with no transaction. Optionally include line items, due date, and customer email (required later for sending). Permissions: Authenticated (merchant or staff) Request:
Variables:
Response:
Input type InvoiceLineItemInput:

6.8.2 Update Invoice (Draft Only)

Update a draft invoice: amount, tax, description, due date, customer email, and/or line items. Replacing lineItems overwrites all existing line items. Permissions: Authenticated (merchant or staff) Request:
Variables (example: update amount and due date only):
Response: Returns the updated Invoice object. If the invoice is not in draft status, an error is returned.

6.8.3 Send Invoice

Moves an invoice from draft to sent: creates a pending transaction and payment link, sets sent_at, and optionally sends an email to customer_email with the payment URL. The customer can open the link to pay; when payment is confirmed, the invoice is marked paid. Permissions: Authenticated (merchant or staff) Requirements: Invoice must be draft and have customer_email set. You must have a wallet for the given blockchain. Request:
Variables:
Response:
Notes:
  • url is the public payment link; share it or rely on the email sent to customer_email.
  • If the email fails, the invoice is still marked sent and the mutation succeeds; the url can be shared manually.

6.8.4 Send Invoice Reminder

Sends a reminder email for an invoice in sent or overdue status and sets last_reminder_at. The email includes the same payment link as when the invoice was sent. Permissions: Authenticated (merchant or staff) Request:
Variables:
Response:
Errors: Invoice must be in sent or overdue and have customer_email; the invoice must have an associated payment link (transaction).

6.8.5 Sync Invoice Status

Manually sync an invoice’s status with its linked transaction (e.g. after payment confirmation). Useful if automatic status updates did not run. The invoice must already have a transaction_id (e.g. created via sendInvoice or a payment link). Permissions: Authenticated (merchant or staff) Request:
Variables:
Response: Returns the updated Invoice. If the linked transaction is confirmed on-chain, the invoice is updated to paid and payment_date is set.

7. Wallet Management

7.1 Add or Update Wallet

Permissions: wallet.manage Request:
Variables:
Response:

7.2 Remove Wallet

Permissions: wallet.manage Request:
Variables:
Response:

7.3 Wallet Balances

Permissions: wallet.view Request:
Response:

7.4 Token Balances

Permissions: wallet.view Request:
Variables:
Response:

8. Customer Management

8.1 List Customers

Permissions: customer.view Request:
Response:

8.2 Upsert Customer

Permissions: customer.manage Request:
Variables:
Response:

9. Error Handling

9.1 Error Response Format

9.2 Standard Error Codes

9.3 Common Error Scenarios

1. Expired Token
Solution: Call refreshToken mutation or redirect to login 2. Permission Denied
Solution: Show user-friendly “You don’t have permission” message 3. Validation Error
Solution: Highlight the email field and show error

10. Refund Operations

10.1 Create Refund Request

Permissions: refund.create (Staff Manager) Request:
Variables:
Response:

10.2 Approve Refund

Permissions: refund.approve (Staff Manager) Request:
Variables:
Response:

10.3 Reject Refund

Permissions: refund.reject (Staff Manager) Request:
Variables:
Response:

10.4 Complete Refund

Permissions: refund.complete (Merchant) Request:
Variables:
Response:

10.5 List Refunds

Permissions: refund.view (Staff Manager) Request:
Variables (optional):
Response:

10.6 Get Refund by Reference

Permissions: refund.view (Staff Manager) Request:
Variables:
Response:

10.7 Get Refund Summary

Permissions: refund.view (Staff Manager) Request:
Response:

11. Product & Price Management

11.1 List Products

Permissions: product.view Request:
Variables:
Response:
Note: The active filter can be used to show only active or inactive products. The category filter allows filtering by product category. Pagination is supported via limit and offset parameters.

11.2 Get Product by ID

Permissions: product.view Request:
Variables:
Response:

11.3 Get Product by SKU

Permissions: product.view Request:
Variables:
Response:
Note: SKU must be unique per merchant. If a product with the given SKU is not found, an error will be returned.

11.4 Get Product Prices

Permissions: product.view Request:
Variables:
Response:

11.5 Create Product

Permissions: product.manage Request:
Variables:
Response:
Note: The name field is required. All other fields are optional. The sku must be unique per merchant. If a product with the same SKU already exists, an error will be returned.

11.6 Update Product

Permissions: product.manage Request:
Variables:
Response:
Note: Only the id field is required. All other fields are optional and will only be updated if provided. If updating the sku, it must remain unique per merchant.

11.7 Delete Product

Permissions: product.manage Request:
Variables:
Response:
Note: This performs a soft delete by setting active=false. The product record remains in the database but is marked as inactive.

11.8 Archive Product

Permissions: product.manage Request:
Variables:
Response:
Note: Archiving a product sets the archivedAt timestamp. Archived products can be filtered out in queries and can be unarchived later.

11.9 Unarchive Product

Permissions: product.manage Request:
Variables:
Response:
Note: Unarchiving a product clears the archivedAt timestamp, making the product available again.

11.10 Create Price

Permissions: product.manage Request:
Variables (One-time price):
Variables (Recurring price with trial):
Variables (Pay-What-You-Want price):
Variables (Usage-based pricing):
Response:
Note:
  • Required fields: productId, amount, currency, type
  • For RECURRING prices, billingPeriod is required (e.g., “month”, “year”)
  • For PAY_WHAT_YOU_WANT pricing, minAmount and/or maxAmount must be provided
  • trialPeriodDays is only allowed for RECURRING prices
  • For usage-based pricing (usageType: METERED), unitLabel is required
  • amount must be greater than 0
  • currency must be a 3-character code (e.g., “USD”, “EUR”)

11.11 Update Price

Permissions: product.manage Request:
Variables:
Response:
Note: Only the id field is required. All other fields are optional and will only be updated if provided. The same validation rules apply as for creating prices (e.g., trial period only for recurring prices).

11.12 Delete Price

Permissions: product.manage Request:
Variables:
Response:
Note: This performs a hard delete, permanently removing the price from the database.

Permission Matrix


Quick Start Example (cURL)


This API reference covers all available endpoints in the StableX platform. For any questions or issues, please contact the development team.