AI integration prompt

You are helping me integrate the DNC LATAM API.

Use these public sources as the source of truth:
- Documentation: https://docs.dnclatam.com
- OpenAPI 3.1: https://api.dnclatam.com/openapi.json

Before writing implementation code, inspect the current OpenAPI contract when
network access is available. Do not invent endpoints, fields, limits, status
codes, or retry behavior.

Security and privacy constraints:
- Treat API keys and phone numbers as sensitive data.
- Never ask me to paste a live API key or customer phone list into chat.
- Use placeholders and synthetic phone numbers in every example.
- Keep the API key in a server-side secret or environment variable.
- Never expose the key in browser or mobile client code.
- Never log Authorization, request phone arrays, prohibited, safe, or invalid
  number arrays, raw idempotency keys, or response bodies containing phone
  numbers.
- Send real requests only from my controlled environment directly to
  https://api.dnclatam.com.

Core request contract:
- POST https://api.dnclatam.com/v1/scrub
- Authorization: Bearer dnc_live_...
- Idempotency-Key is required.
- Body: {"country":"mx"|"ar"|"co"|"es"|"au"|"sg","phones":["..."]}
- This six-country union is the technical API contract, not the commercial
  catalog. The current sellable catalog is MX/AR/CO. ES/AU/SG are coming
  end of September 2026 (not live yet) and must be treated as roadmap,
  never as enabled coverage. Every real
  request still requires a matching Country Purchase and country
  availability/activation. Colombia is sellable and operational; a successful
  initial payment activates its complete API access immediately, without a
  manual approval or activation step.
- Generate one opaque random idempotency key per logical request.
- Reuse that key only for an exact retry of the same country and phone array.
- Never put PII in the idempotency key.
- For larger or slower work, use POST https://api.dnclatam.com/v2/scrub with
  the same body and idempotency rules. It accepts at most 500,000 inputs and a
  raw JSON body of at most 25 MiB; both limits apply and the first reached
  limit controls admission.
- A v2 admission returns 202 with an opaque lowercase UUID `job_id`. Poll GET
  /v2/scrub/{job_id}, read
  GET /v2/scrub/{job_id}/result after success, or request cancellation with
  POST /v2/scrub/{job_id}/cancel. Do not create a new job for every poll.
- v2 results use transient encrypted retention: attached input becomes due for
  purge at terminal state and an unknown upload becomes due for revalidation
  at the 24-hour active-job hard cap; failed cleanup remains retryable until
  absence is verified. Successful results last 7 days, and non-phone metadata
  lasts 30 days.

Response semantics:
- prohibited_numbers_to_call: structurally valid original inputs found in the
  selected DNC registry; do not call them.
- safe_numbers_to_call: structurally valid original inputs not found in that
  registry at the time of the check. Here, safe is limited to this DNC registry
  result; it does not prove consent, reachability, or universal legal
  permission to call.
- invalid_numbers: inputs that failed structural validation or were explicitly
  rejected by the selected registry, each with input and reason. Preserve the
  original relative order within this array; never classify a rejected input
  as safe.
- summary.total_checked counts all submitted elements, including invalid
  inputs and duplicates.
- summary contains prohibited_numbers, safe_numbers, and invalid_numbers
  counts, and their sum equals summary.total_checked.
- Do not generate or parse the obsolete matched, clean, invalid, or stats
  response fields.
- Preserve duplicates and understand that response arrays contain the original
  input strings.

Reliability requirements:
- Distinguish rate_limit_exceeded from customer_quota_exceeded.
- Distinguish country_service_maintenance,
  country_service_temporarily_unavailable, and platform_failure.
- For v2 result retrieval, distinguish `job_result_not_ready` (queued,
  running, failed, or cancelled) from `job_expired` and
  `job_result_expired` (410). Failed and cancelled jobs have no complete
  result; expired jobs are not retriable by polling.
- Honor Retry-After for retryable 409, 429, and 503 responses.
- Retry only the exact logical request with the same idempotency key.
- Use bounded exponential backoff with jitter for transient failures.
- Do not retry validation, authentication, billing, entitlement, quota, or
  idempotency-conflict errors without corrective action.

When answering:
1. State any assumptions.
2. Provide production-oriented server-side code.
3. Include structured error handling and safe, aggregate-only observability.
4. Include a synthetic test that does not consume or reveal customer data.
5. Explain how I can verify authentication, idempotency, response partitioning,
   retries, and zero-data-retention behavior.

My requested language/framework and integration task:
[DESCRIBE THE TASK HERE]

Build a TypeScript service for a Node.js worker that scrubs Mexico batches,
returns `safe_numbers_to_call` to the caller, and retries temporary capacity
errors.

Review my Python integration for incorrect idempotency and unsafe logging.
Do not call the API; return findings and corrected code only.

Explain a 409 idempotency_key_reused response and show how to model logical
request IDs in our queue.