Lightning API

The Lightning API is our HTTPS-based payment API designed for quick integration with the x402 protocol. Send a request and we handle everything: payment verification, transaction building, signing, and broadcasting.

Overview

Base URL: https://api.yuzu402.dev

Authentication: Bearer token in Authorization header

Rate Limits:

  • Standard: 100 requests/minute

  • Premium: 1,000 requests/minute

Endpoints

Send Payment

Execute a payment over the x402 protocol. This endpoint handles the buyer flow, allowing you to programmatically send payments to access protected resources.

Endpoint: POST /payment/send

Request Body:

Parameter
Type
Required
Description

walletAddress

string

Yes

Your wallet address (EVM or Solana format)

recipientAddress

string

Yes

Payment recipient's wallet address

amount

number

Yes

Payment amount in native currency (min: 0.001, max: 100)

resource

string

No

Protected resource URL being accessed

metadata

object

No

Additional payment metadata (description, reference ID, etc.)

priorityFee

number

No

Network priority fee (default: auto, range: 0.00001-0.01)

Example Request:

Success Response (200):


Receive Payment

Verify and process incoming x402 payments. This endpoint handles the seller flow, validating payment proofs and confirming receipt of funds for protected resources.

Endpoint: POST /payment/receive

Request Body:

Parameter
Type
Required
Description

walletAddress

string

Yes

Your receiving wallet address

paymentProof

string

Yes

Cryptographic payment proof (from X-PAYMENT header)

expectedAmount

number

Yes

Expected payment amount

resource

string

No

Protected resource being accessed

facilitatorUrl

string

No

Facilitator URL for payment verification (default: x402 network)

timeout

number

No

Verification timeout in seconds (default: 30)

Example Request:

Success Response (200):


Get Payment Status

Retrieve the status and details of a specific payment transaction.

Endpoint: GET /payment/status/{paymentId}

Parameters:

Parameter
Type
Required
Description

paymentId

string

Yes

Payment transaction ID (path parameter)

Example Request:

Success Response (200):


Get Payment History

Get payment transaction history for a specific wallet address. Returns both sent and received payments.

Endpoint: GET /payment/history/{walletAddress}

Parameters:

Parameter
Type
Required
Description

walletAddress

string

Yes

Wallet address (path parameter)

type

string

No

Filter by type: "sent", "received", or "all" (default: "all")

limit

number

No

Number of results (default: 50, max: 500)

offset

number

No

Pagination offset (default: 0)

Example Request:

Success Response (200):

Error Responses

All endpoints may return these common errors:

400 Bad Request

Invalid parameters:

401 Unauthorized

429 Rate Limit

Common Error Codes

Code
Description
Solution

INSUFFICIENT_BALANCE

Not enough funds for payment + fees

Add more funds to wallet

INVALID_PAYMENT_PROOF

Payment proof invalid or expired

Retry payment with fresh proof

PAYMENT_VERIFICATION_FAILED

Facilitator could not verify payment

Check payment status and retry

INVALID_RECIPIENT

Recipient address invalid or doesn't exist

Verify recipient address

RATE_LIMIT

Too many requests

Slow down requests

See Error Handling for complete error documentation.

Code Examples

JavaScript/TypeScript

Python

Best Practices

  1. Always Handle Errors: Implement robust error handling for all payment requests

  2. Verify Payment Proofs: Always validate payment proofs on the seller side before granting access

  3. Monitor Transactions: Track payment signatures and verify confirmations on-chain

  4. Respect Rate Limits: Implement exponential backoff strategies for retries

  5. Secure API Keys: Never expose keys in client-side code or public repositories

  6. Test with Small Amounts: Validate integration with minimal payment amounts first

  7. Use Metadata: Include descriptive metadata for easier payment tracking and reconciliation

  8. Handle 402 Responses: Implement proper HTTP 402 Payment Required handling in your client

  9. Set Appropriate Timeouts: Configure reasonable timeout values for payment verification

  10. Cache Payment Proofs: Store payment proofs temporarily for retry scenarios

x402 Protocol Integration

Yuzu402 is designed to work seamlessly with the x402 protocol. For direct x402 integration:

  • Buyers: Use client libraries like x402-fetch or x402-axios to automatically handle 402 responses

  • Sellers: Implement x402 middleware for your framework (Express, Next.js, FastAPI, etc.)

  • Learn More: Visit x402.org for protocol documentation and specifications

Next Steps

Last updated