Writing
Notes on the parts of outbound HTTP that bite
Five problems that show up in every codebase that calls a URL it did not hardcode: SSRF filters that do not hold, the metadata service, egress allowlists, duplicate webhooks and model-chosen targets. Each one ends in code you can copy.
What actually blocks SSRF (and what quietly does not)
Most SSRF filters check the hostname. The attack does not live in the hostname — it lives in what the hostname resolves to at connect time.
169.254.169.254: the address your outbound code must never reach
One GET to a link-local address can return credentials that outlive your incident response. It is reachable from anywhere inside the instance.
When a partner asks you to allowlist an IP — and you deploy on Vercel
The request looks like a five-minute ticket. On a serverless platform it is a NAT gateway, a VPC connector or a new vendor.
At-least-once is not a bug: receiving webhooks without double-charging
Exactly-once delivery over an unreliable network is impossible. At-least-once plus an idempotent handler is the honest equivalent.
Your agent chose the URL. Now it can reach your VPC.
The tool schema says url: string. That is a wide-open outbound request from inside your network, chosen by a model that can be talked into anything.
Start from a use case
Where these answers live in the product
Try it with 5,000 free trips.
No card, no subscription, and the balance never expires.