Lift API reference

The Lift endpoint combines ERC-4337 bundler methods with ERC-7677 paymaster methods. Copy the complete URL from the Lift integration guide for your environment:

POST {LIFT_API_ORIGIN}/api/lift/rpc/11155111
Authorization: Bearer {LIFT_API_KEY}
Content-Type: application/json

LIFT_API_ORIGIN is the API's HTTP origin, not the console URL. Only the configured and enabled Sepolia pilot is accepted.

Request format

Send one JSON-RPC 2.0 object with method, array params, and id:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "eth_supportedEntryPoints",
  "params": []
}

The ID may be a string of up to 100 characters, a safe integer, or null. Omitted IDs, JSON-RPC notifications, and batches are unsupported. Query strings and browser-origin requests are rejected.

Methods

The EntryPoint is 0x0000000071727De22E5E9d8BAf0edAc6f37da032. In paymaster parameters, the chain ID is the hexadecimal quantity 0xaa36a7, not a decimal string.

Receipt and operation lookups are scoped to your integration. An unknown hash, or a hash belonging to another integration, returns null. eth_sendUserOperation accepts only an operation matching a current sponsorship journal entry issued to the authenticating integration and key version.

Sponsorship context

{
  "policyId": "YOUR_LIFT_POLICY_ID",
  "requestId": "payment:order-123:attempt-1"
}

policyId is required and must identify an enabled policy belonging to the integration. requestId is optional and may contain 1–128 letters, digits, underscores, colons, periods, or hyphens. Additional context fields are rejected.

Without requestId, Lift derives the request identity from the canonical operation fingerprint. Reuse the same identifier and identical operation when retrying. An identifier cannot authorize a different operation. A chain, sender, and nonce cannot have another unreleased reservation or settlement, including across integrations.

UserOperation fields

The API uses the unpacked v0.7 representation. Unknown fields are rejected; do not send v0.6 initCode or paymasterAndData fields.

Canonical quantities use 0x0 for zero and omit leading zeroes for other values. Byte strings use an even number of hex digits. The final sponsorship request requires positive call, verification, pre-verification, and maximum-fee values; stub/estimation parsing permits missing numeric values as zero.

The current paymaster fields reserve 100000 verification gas and 0 post-operation gas. Use the fields returned by the paymaster client rather than constructing or modifying its signed data. Sign the resulting full UserOperation with the account afterward.

Errors

Always inspect both the HTTP status and JSON-RPC body. Application-level refusals normally arrive with HTTP 200 and a JSON-RPC error object.

Some internal failures are deliberately summarized as -32504; do not infer that a reservation has been released from that code alone.

Limits

• 120 requests per minute per integration, including reads and retries.
• 130,000 bytes per request body.
• One JSON-RPC request per HTTP request and one permitted call per UserOperation.
• Sponsorship signatures valid for at most five minutes.
• At most 100 pending operations per policy, plus deployment-specific chain and gas limits.

Use bounded polling. A client timeout does not prove rejection or non-inclusion; check the existing operation before creating another request.

Configuration status

GET {LIFT_API_ORIGIN}/api/lift/health

This unauthenticated route reports the service, configured chains, and capabilities. status: "configured" reports configuration, and liveReadinessVerified: false explicitly means it does not verify current funding, signing, bundling, or chain health. Treat a successful supported request and confirmed operation as separate checks from this configuration response.

An error response can contain only the service and configuration-error status with HTTP 503. A configured Roles onboarding flow does not enable account-deployment sponsorship through the public paymaster API.