All docs

Security Model

SendItWhenever sends HTTP requests on your behalf, so it's built to be a safe relay — for you, for your targets, and for the rest of the internet.

SSRF protection

Because we make outbound requests to a URL you provide, we defend hard against Server-Side Request Forgery (SSRF) — attempts to make the relay reach internal or sensitive addresses.

Scheme and port. targetUrl must be:

  • https:// only — plain http:// is rejected.
  • Port 80 or 443 only.
  • No embedded credentials (user:pass@host is rejected).

Blocked address ranges. A target is rejected if it resolves to a private, reserved, or special-use address, including:

  • Loopback (127.0.0.0/8, ::1)
  • Private networks (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, fc00::/7)
  • Link-local — including the cloud metadata address (169.254.0.0/16, notably 169.254.169.254)
  • Carrier-grade NAT, multicast, benchmarking, and documentation/test ranges

DNS rebinding defense. The check isn't just at creation time. Immediately before firing, we re-resolve the hostname and inspect every address it resolves to — if any is in a blocked range, the delivery is refused. We then connect to the resolved address we vetted, so a DNS answer can't be swapped between the check and the connection.

No redirects. We never follow 3xx redirects — a redirect could otherwise bounce a request to a blocked address. Point your schedule at the final URL.

If a target is blocked at fire time, the schedule goes to the dead-letter queue (dead); see Reliability.

Encryption at Rest

Your payload is encrypted with AES-256-GCM the moment it's stored, and decrypted only in memory, only at the instant of firing. The plaintext is never written to logs, databases, or error messages, and is never returned by the API. Responses expose only the size and a "has payload" flag.

Outbound signing

Every webhook we send is signed with HMAC-SHA256 in the X-SendIt-Signature header, so your endpoint can verify authenticity and integrity. See Verifying Webhooks.

Abuse limits you might encounter

To keep the relay from being weaponized, a few protective limits apply. Most users never hit them, but if you do, here's what's happening:

  • Per-target rate. Sustained bursts to a single target host from one account are rate-limited.
  • API rate limits. Excessive requests from one key or IP return 429 RATE_LIMITED.
  • Target denylist. Specific hosts can be blocked from being targeted at all.
  • Signup protection. Account creation is rate-limited per IP to curb farming.

If you have a legitimate high-volume use case, get in touch rather than working around these.