Bundler REST API

DALP exposes each bundler and paymaster action as a typed v2 REST resource. Authenticate every request with an API key for the organization whose wallets you operate. Operations that name a sender also require the active organization and chain context to resolve to that wallet.

Resources

The live /api/v2/spec.json document defines each request, response, status, and public error schema. Methods that do not apply to the active organization's configuration return an ordinary public HTTP error instead of a protocol method-not-found envelope.

Discover the EntryPoint

curl "$DALP_API_URL/api/v2/bundler/entry-points" \
  --header "X-Api-Key: $DALP_API_KEY"

Read the EntryPoint from the response instead of hardcoding one. Private and local networks can register a different address. An unavailable directory registration or indexing gap returns a typed public failure with remediation guidance.

Submit a UserOperation

curl --request POST \
  "$DALP_API_URL/api/v2/bundler/user-operations" \
  --header "Content-Type: application/json" \
  --header "X-Api-Key: $DALP_API_KEY" \
  --data @user-operation.json

The sender wallet must belong to the authenticated organization. For a weighted multisig wallet, one call can record a signature without crossing the submission threshold. Read the UserOperation resource until it reaches a pending, submitted, or mined state; do not treat the returned hash alone as proof that it entered the mempool.

Duplicate signatures on an active approval are idempotent. A hash tied to another approval flow or a terminal approval returns a public error and does not silently enqueue new work.

Estimate gas

Call POST /api/v2/bundler/user-operation-gas-estimates with the candidate UserOperation before collecting final signatures. The previewed nonce, call data, gas limits, fee values, paymaster fields, and signature shape contribute to the signed hash. Re-estimating after signatures are collected can invalidate them.

Request sponsorship

Use POST /api/v2/bundler/paymaster-stub-data during estimation and POST /api/v2/bundler/paymaster-data before submission. These resources require gas sponsorship to be enabled for the organization and an available system paymaster for the sender.

For funding and signer-key operations, see System paymasters. For the architecture behind sponsorship, see Paymasters and gas sponsorship.

Error handling

Bundler resources use the same public HTTP error object as the rest of v2. Branch on error.id, error.status, and error.retryable; preserve the request ID when escalating a failure. A retryable dependency failure is not evidence that the UserOperation was never accepted, so read by hash before resubmitting.

See Error handling for the shared envelope and recovery rules. SDK users can keep the established eight method names through createDalpBundlerClient; that client calls these REST resources directly.