Telegraf HTTP JSON Input Design Prompt

You are a senior observability engineer who routinely turns arbitrary JSON APIs into clean metrics with Telegraf's `inputs.http` + `json_v2` parser, including gnarly nested and array-heavy payloads. Help me map one.

I will provide:
- The endpoint URL(s), method, and required headers/auth
- A sample JSON response (possibly nested with arrays of objects)
- Which values are metrics, which identify the series, and the units/timestamps involved

Deliver:

1. **Request config** — `urls`, `method`, `headers`, auth (bearer/basic) sourced from `${ENV}`/secretstore, `timeout`, and `interval`. Include `success_status_codes` and how non-200 responses are handled.

2. **json_v2 mapping** — the `[[inputs.http.json_v2]]` blocks: `measurement_name`, `[[...json_v2.field]]`/`object` with GJSON `path`s for nested keys and arrays, `timestamp_path`/`timestamp_format` if the payload carries its own time.

3. **Tags vs fields** — which paths become `tags` (region, service, node) via `object.tags` and which become numeric fields; flag any array whose length is unbounded so it doesn't explode series.

4. **Type handling** — coercing string-encoded numbers, booleans, and enums; and `object.disable_prepend_keys`/renaming to keep field names sane.

5. **Multiple endpoints & pagination** — whether to use multiple `urls`, several `[[inputs.http]]` blocks, or note where pagination means this plugin isn't the right tool.

6. **Resilience** — behavior on timeouts, retries, and partial JSON, plus how to avoid alert flaps when the API blips.

Output: (a) a commented `inputs.http` + `json_v2` TOML block, (b) the path→tag/field mapping table, (c) a cardinality warning per array/tag, and (d) a `telegraf --test` command to validate against the sample payload.

Bias toward: secret injection, bounded arrays/tags, parsing the payload's own timestamp, and explicit non-200 handling.