About 411data

411data is an agent-native lead and business-data enrichment platform. It packages reverse phone and person lookup, LLM web-search enrichment, and agentic lead-session orchestration behind a small, well-documented HTTP surface — hosted enrich agent plus REST API — so you can enrich leads without integrating dozens of vendor APIs directly.

Why this exists

Data enrichment is fragmented: every vendor has different coverage, pricing, and response shapes. Agents that try to wire vendors ad hoc lose on reliability, cost tracking, and audit trails.

411data packages enrichment behind a small HTTP surface with request/response storage for every call and bill-on-match pricing so you only pay when enrichment succeeds.

Product surface (live today):

  1. Reverse phone lookup — enrich/phone ($0.330/call default).
  2. Person enrichment — by name, address, or reverse phone on enrich/person ($0.500/call default).
  3. LLM web-search enrichment — business-name hunt when structured vendors lack coverage ($1.00 min on match; 30% markup when COGS > $1).
  4. Agentic lead-session — multi-tool enrichment with backfill graph ($1.500 base; usage true-up when session COGS × margin exceeds base).
  5. Async enrich jobs — POST /api/v1/enrich/jobs + poll for long websearch / lead-session work (bill up to $1.50 default, override to $50).
  6. Support tickets — open a support thread via API or hosted enrich agent ($0.010/call default).

Catalog-tier routes (enrich/email, enrich/company, leads/search) remain in the codebase but are offline by default until vendor datasets return.

Built for agents first

Abuse protection

The service runs behind layered abuse protection so it stays useful for real agents without forcing every caller through a captcha. Per-agent quotas and x402 paywalls are the public-facing parts of that — see /pricing and /x402. Specific limits, bucket structures, and detection rules are intentionally not documented; any caller who runs into one will see a 429 (or 402) with a Retry-After and the next reasonable action.

"Deceptive request" warning when signing the budget commitment

As of 2026-05-21 we no longer use a Permit2 typed-data signature for the optional mint-time budget commitment, so MetaMask / Rabby / Blowfish-backed wallets should display the second signature on /connect as a normal "Sign-in"-style prompt rather than a red "deceptive request" interstitial. If you still see a warning, clear your browser cache (an old SPA build is still loaded) and retry.

Background — what changed and why

The original Phase 3A design had the SPA ask your wallet to sign an EIP-712 Permit2 PermitWitnessTransferFrom payload at mint time. The spender field in that payload pointed at the canonical x402-foundation x402UptoPermit2Proxy contract (0x4020A4f3b7b90ccA423B9fabCc0CE57C6C240002). That address is the official x402 v2 proxy, source code is verified on Basescan as x402UptoPermit2Proxy ("Exact Match"), and has been used in tens of thousands of legitimate transactions — but several wallet security tools (MetaMask SafeChecker, Rabby, Blowfish) started displaying a "deceptive request" warning against it. The exact reason is unknown and is being tracked upstream at x402-foundation/x402#2416 ("Proxy address flagged as malicious - Not a good look for users"). Our working hypothesis is that the address was deliberately vanity-mined to match the "x402" brand (0x4020…0002), the contract is relatively new (deployed 2026-03-30), and Etherscan hasn't issued a public name tag yet — together those traits trip the static-heuristic pattern wallets score as "potentially impersonating".

Rather than ask buyers to dismiss a scary warning on every mint, we switched the budget commitment to a SIWE-shaped plain-text message signed via EIP-191 personal_sign. No contract spender is referenced in the signed payload, so wallets render it as a friendly sign-in prompt instead of a transaction approval. The security guarantees are identical:

If you'd rather skip the budget commitment entirely, uncheck "Commit a USD budget" on /connect — you'll only sign the SIWE login message and your wallet will be prompted for a fresh per-call signature at x402 settle time. Agent SDKs auto-sign these in the background.

Bearer tokens — save them; limited recovery exists

Once an agent token is issued, the server stores only its sha256 hash — the raw bearer is shown to you exactly once at first mint and never again. Treat it like a root password: vault, env file, offline copy.

While you still have the bearer:

Bearer lost everywhere but you still control the mint wallet:

Idempotent re-mint of /wallet-register from the same wallet refreshes allowance metadata but does not re-reveal the bearer (token is null).

Wallet ownership alone is intentionally not enough to recover the bearer — otherwise a stolen seed would auto-escalate into API-key takeover. Recovery adds a usage-memory check and a paid fee to raise the bar.

Get in touch