Bitcoin Payment Intelligence • Read-only • Agent-ready
Understand a Bitcoin payment before you approve it.
One structured call validates Ark, Lightning, on-chain, and multi-rail payment instructions; checks network and amount consistency; compares available routes; and surfaces expiry, fee, privacy, and callback risks.
5 sats / call
POST /api/payment-intel
Tor-only live checks
Never sends funds
Try 10 calls for 50 sats →
Formats understood
- Ark and Bark addresses with Bech32m and envelope checks
- BIP-321 multi-rail Bitcoin payment URIs
- BOLT11 invoices with cryptographic signature verification
- BOLT12 offers, requests, and invoices
- LNURL and Lightning addresses
- Silent Payments and on-chain Bitcoin addresses
Safety by default
- Exact integer sats and millisats; no floating-point money math
- Network mismatch, duplicate, expiry, and required-field guards
- Proof callbacks are classified but never invoked
- Private, loopback, and unsafe live callback targets are rejected
- Destination values are excluded from application logs
- Every response requires explicit wallet approval
Example request
curl -X POST https://arkapi.dev/api/payment-intel \
-H "Authorization: Bearer ak_your_token" \
-H "Content-Type: application/json" \
-d '{
"destination":"bitcoin:bc1q...?amount=0.00001000&lightning=lnbc...&ark=ark1...",
"expected_network":"mainnet",
"priority":"economy",
"live_checks":false
}' | jq
The destination may be one payment instruction or a BIP-321 URI containing several. Set live_checks only when you want ArkAPI to resolve Lightning-address or LNURL metadata over Tor.
What comes back
validationFormat, checksum, signature, network, expiry, amount, and required-parameter findings.methodsNormalized Ark, Lightning, and on-chain payment methods with per-method issues.routesAvailable rails, settlement profile, route rationale, and rough on-chain fee range when available.recommendationDeterministic preference for a valid Ark route, then Lightning, then on-chain—never an automatic payment.privacyWhether any live lookup ran, which transport it used, and what an external provider could observe.
{
"valid": true,
"payable": true,
"recommended_rail": "ark",
"amount": {"sats": 1000, "msats": 1000000, "source": "uri"},
"privacy": {"destination_logged": false, "live_checks": false},
"requires_user_approval": true
}
Route intelligence
Current generic on-chain fee rates are fetched through Tor and converted into a clearly labeled rough transaction-size range. When the likely fee meets or exceeds the payment, the response warns that the route may be uneconomic.
Lightning fees and Ark server compatibility remain wallet-dependent, so ArkAPI labels those as requiring a wallet quote instead of inventing certainty.
Designed for agents
Stable schema versioning, explicit severity levels, machine-readable issue codes, normalized rail names, deterministic recommendations, and bounded network behavior make this endpoint safe to place before a wallet approval step.
Discover it through OpenAPI, llms.txt, the agent manifest, the ArkAPI agent skill, or the live catalog.
Where it fits
walletsPreflight a pasted invoice, address, QR payload, or BIP-321 URI before showing the final approval screen.agentsTurn an untrusted payment string into bounded, machine-readable findings before any wallet tool is allowed to act.checkoutNormalize multi-rail requests and explain which valid route is available without silently changing the amount.supportDiagnose wrong-network addresses, expired invoices, unsafe callbacks, and amount disagreements without handling keys.
Important boundary
Payment Intel is an analysis service, not a wallet. It does not hold keys, create signatures, route a Lightning payment, contact an invoice callback, or broadcast a transaction. A compatible wallet must independently verify the final destination, amount, fees, and route immediately before payment.