Paymaster API

The Paymaster API signs or sponsors transactions and reads paymaster balance state through API-key guarded runtime endpoints.

Auth

Use an API key:

Authorization: Bearer sk_your_api_key

Developer-portal admin endpoints are intentionally omitted from this reference.

Routes

Method	Route
`GET`	`/paymaster/test`
`GET`	`/paymaster/balance`
`POST`	`/paymaster/sign`
`POST`	`/paymaster/sponsor`
`POST`	`/paymaster/sponsor/bundle`

Get balance

GET /paymaster/balance Query parameters:

Parameter	Type	Description
`network`	string	`devnet` or `mainnet`; empty defaults to `mainnet`
`kind`	enum	`PAYMASTER_KIND_API` or `PAYMASTER_KIND_IDP`

Response:

{
  "configured": true,
  "kind": "PAYMASTER_KIND_API",
  "id": "paymaster_123",
  "address": "PaymasterPublicKey",
  "label": "Production paymaster",
  "balanceLamports": "1000000000",
  "balanceSol": 1
}

Sign a transaction

POST /paymaster/sign

{
  "base58_encoded_transaction": "BASE58_TRANSACTION",
  "network": "devnet"
}

Response:

{
  "request_id": "req_123",
  "signed_transaction": "BASE58_SIGNED_TRANSACTION"
}

POST /paymaster/sponsor

{
  "base58_encoded_transaction": "BASE58_TRANSACTION",
  "network": "devnet",
  "idempotencyKey": "sponsor:order_123"
}

Response:

{
  "request_id": "req_123",
  "signature": "TransactionSignature",
  "spent_by_paymaster": "5000"
}

There is no status field on this response. A returned signature means the Solana RPC accepted the transaction; it may still be pending and is not proof of confirmation or finality. Track the signature through your RPC provider if your product needs either.

Send idempotencyKey whenever your application may retry. A matching retry returns the original response rather than sponsoring twice. Without a key, treat a failed sponsor call as unresolved rather than replaying it blindly.

POST /paymaster/sponsor/bundle submits related transactions together.

{
  "base58_encoded_transactions": [
    "BASE58_TRANSACTION_ONE",
    "BASE58_TRANSACTION_TWO"
  ],
  "network": "mainnet",
  "idempotencyKey": "sponsor-bundle:order_123"
}

Response:

{
  "request_id": "req_123",
  "bundle_id": "bundle_123",
  "signatures": ["SignatureOne", "SignatureTwo"],
  "estimated_spent_by_paymaster": "10000"
}

Constraints:

Constraint	Detail
Network	mainnet only
Size	one to five transactions
Order	`signatures` are returned in bundle order
Cost	`estimated_spent_by_paymaster` is an estimate, not a settled charge

A returned bundle_id means Jito accepted the bundle. The bundle may still be pending; acceptance is not confirmation or finality.

Transaction encoding

Sponsor and sign requests take base58-encoded transactions. The Developer SDKs accept base64 prepared transactions and convert them for you — see Sponsor & Submit. Paymaster limit configuration is handled through developer-portal admin surfaces, not API-key runtime endpoints.

Start Here

Runtime APIs

Boundaries

Paymaster API

Auth

Routes

Get balance

Sign a transaction

Transaction encoding

​Auth

​Routes

​Get balance

​Sign a transaction

​Sponsor a transaction

​Sponsor a bundle

​Transaction encoding

Auth

Routes

Get balance

Sign a transaction

Sponsor a transaction

Sponsor a bundle

Transaction encoding