Skip to main content

2 posts tagged with "Engineering"

Technical deep dives into Pry internals

View All Tags

Building 109 Store-Ready Apify Actors with the Pry Actor Factory

ยท 3 min read
The Pry Team
Pry Engineering

Pry ships 109 store-ready Apify Actors. Hand-writing 109 actor packages โ€” each with spec files, a Dockerfile, pay-per-event wiring, and a store listing โ€” would be a maintenance nightmare. So we didn't. Every actor is generated from a single declarative spec by the open-source Actor Factory.

One spec, a complete actorโ€‹

An ActorSpec describes what the actor does and how it's priced. The factory generates everything else:

from pathlib import Path

from actor_factory import ActorSpec, PricingEvent, generate_actor

spec = ActorSpec(
name="price-watcher",
title="Price Watcher",
description="Track e-commerce prices with change detection.",
version="1.0",
pricing_events=(
PricingEvent(
name="price-captured",
title="Price captured",
description="One product price captured.",
price_usd=0.001,
),
),
)
generate_actor(spec, Path("actors/price-watcher"))

The output is a complete .actor package: Apify spec files, Dockerfile, PPE runtime that emits events only on successful processing, and a store-ready README. Generated actors pass Apify's automated quality gates on the first publish.

PPE pricing with an economics modelโ€‹

Pay-per-event pricing is easy to get wrong: price too high and nobody runs the actor; too low and every run loses money. The factory includes an economics model that computes break-even pricing from real inputs โ€” proxy bandwidth, browser minutes, LLM tokens, and Apify's platform fees โ€” then applies a margin.

Two synthetic events (apify-actor-start, apify-default-dataset-item) are billed by the platform automatically; the model accounts for them so the listed per-item prices stay honest. The result: prices from $0.001 to $0.003 per event, verified against cost, not guessed.

The 15 new market-gap actorsโ€‹

The latest batch targets niches with no first-class Apify coverage โ€” places where demand exists but the store has nothing good:

  • App store ranks โ€” Apple App Store + Google Play rankings, reviews, ASO signals
  • AI model pricing โ€” LLM API price tracking across providers
  • GPU cloud prices โ€” GPU instance pricing across cloud providers
  • EV charging stations โ€” locations, pricing, availability
  • Insurance rates โ€” public quote and rate signals
  • Ticket resale โ€” secondary-market event ticket price monitoring
  • โ€ฆplus market-intel, pricing/rate, and data-pipeline niches

Each of these went through the same pipeline: define the spec, let the economics model set PPE prices, generate, and publish. Total authoring cost per actor: one spec file.

Generate and publishโ€‹

The full loop:

# 1. Define your spec (see above), then generate
python -m actor_factory.cli generate actors/price-watcher

# 2. Test locally
cd actors/price-watcher && apify run

# 3. Publish to the Apify Store
apify push

Because every actor shares the same generated skeleton, a fix to the PPE runtime or the anti-bot tier selection propagates to the whole catalog with a regeneration โ€” 109 actors, one source of truth.

Build your ownโ€‹

The Actor Factory is open source under the Pry repo. If you need an actor we don't ship, define a spec and generate it โ€” or email us and we'll add it to the catalog.

x402 Payments โ€” How AI Agents Pay for Scraping

ยท 3 min read
The Pry Team
Pry Engineering

AI agents increasingly need to fetch web data: prices, listings, articles, compliance records. But agents can't fill out signup forms or click "confirm email". x402 solves this by making the HTTP status code 402 Payment Required machine-payable: the API asks for crypto, the agent pays from a wallet, and the call proceeds. No account, no API key โ€” in the x402 lane, the payment is the credential.

The x402 protocol in one flowโ€‹

x402 (revived by Coinbase's x402 spec) works like this:

  1. The agent calls a paid endpoint with no payment.
  2. The server responds 402 Payment Required with a PAYMENT-REQUIRED header โ€” a Base64-encoded JSON body containing the receiving wallet, amount, asset, and facilitator.
  3. The agent signs and broadcasts a payment (typically USDC) to that wallet.
  4. The agent submits the transaction to the server, which verifies it on-chain and returns an access token.
  5. The agent replays the token (X-Payment-Id header) until it expires.
curl https://api.pryscraper.com/v1/x402/pricing
# {"scrape": {"price_usd": 0.001}, "crawl": {"price_usd": 0.01}, ...}

Prices are per operation and published at /v1/x402/pricing, so an agent can budget before it spends: one page costs a tenth of a cent, a thousand-page bulk crawl costs ten cents.

EIP-3009: the settlement primitiveโ€‹

On EVM chains, Pry verifies payments via EIP-3009 (transferWithAuthorization) โ€” the USDC standard for gasless, signature-based transfers. The payer signs an authorization; the facilitator (or the server itself, via EIP-7702 self-verify) submits it on-chain. Permit2 and plain native transfers are also supported, so USDT, ARB, ETH, and WETH work alongside USDC.

Verification is real: the transaction is confirmed on-chain before an access token is issued, with a configurable TTL (PRY_X402_PAYMENT_TTL, default 3600s).

Multi-chain treasuries: EVM, Solana, Tronโ€‹

A Solana address can't receive an EVM transfer, so Pry keys receiving wallets by CAIP-2 network id โ€” one treasury per chain family:

PRY_X402_ENABLED=true
PRY_X402_WALLET_BASE=0x... # EVM treasury (shared across EVM chains)
PRY_X402_WALLET_SOLANA=... # distinct base58 address
PRY_X402_WALLET_TRON=... # distinct T-prefix address

Pry accepts payments across seven chains: Base, Ethereum, Arbitrum, Optimism, and Polygon (EVM, USDC/USDT and native assets), Solana (SPL: SOL/USDC/USDT), and TRON (TRC-20: USDT/TRX). EVM settlement is turnkey; Solana runs through an SPL/facilitator verifier; TRON is scaffolded for operators who enable it explicitly.

How agents auto-pay via MCPโ€‹

The friction point for agents is implementing the payment flow. Pry exposes 76 MCP tools, so an agent with an MCP client and a funded wallet can scrape without any bespoke payment code: the tool call returns the 402 challenge, the agent's wallet layer signs the EIP-3009 authorization, and the retry carries the payment. From the agent's perspective it's just another tool call that costs fractions of a cent.

This is the model we expect to win for machine-to-machine APIs: no onboarding funnel, no API-key provisioning, no minimum commitments โ€” just a signed payment per call, settled on-chain.

Try itโ€‹

Commercial licensing and hosted plans: [email protected].