---
title: "Parsed Enterprise-lead capture bounds + source-IP resolution proof"
method: GET
path: "/api/v1/admin/lead-capture-budget"
tags: ["admin"]
---

# Parsed Enterprise-lead capture bounds + source-IP resolution proof

`GET /api/v1/admin/lead-capture-budget`

## Request

- Base URL: `https://api.badgeia.com`
- URL: `https://api.badgeia.com/api/v1/admin/lead-capture-budget`
- Auth: none declared

Expose the parsed capture-side bounds and prove source-IP resolution works.

Both settings here traverse three CD env-render hops, and the per-source
notification allowance has a genuinely SILENT failure mode: it buckets on
the trusted-XFF client IP, so if ``TRUSTED_PROXIES`` ever drifts away from
Caddy's container address, every caller collapses into ONE bucket and
real-time lead notices go quiet after the daily allowance. Leads are still
captured and still listed in /admin — but the alerting this exists to
protect would be dead with no error anywhere. Rule #13 forbids the SSH that
would otherwise diagnose it, so the check has to be an HTTP surface.

``xff_honored`` is the load-bearing field: it must be true in prod. False
behind Caddy means TRUSTED_PROXIES is wrong and every lead shares a bucket.

``source_ip`` is the CALLER's own address (the authenticated admin's), so
this discloses nothing the caller doesn't already know.

Shape:
    {
      "notify_max_per_source_per_day": 5,
      "waitlist_retention_days": 365,
      "retention_scheduler_enabled": false,
      "source_ip": "203.0.113.9",
      "xff_honored": true,
      "peer_ip": "172.30.10.2"
    }

## Response `200`

Successful Response

- object

---

[API](https://skmtc.dev/badgeia/apis/badge.md) · [All operations](https://skmtc.dev/badgeia/apis/badge/llms.txt) · [OpenAPI document](https://skmtc.dev/badgeia/apis/badge/revisions/7e7f7fee8b77?raw)