Build against hellojade with an AI coding agent.

You are integrating my lead source with the hellojade Partner Intake API.

Read these first, in this order, and treat them as the source of truth over anything you already know:
1. https://intake.hellojade.ai/api/INTEGRATION.md  (the integration brief — read it front to back)
2. https://intake.hellojade.ai/api/openapi.json  (the OpenAPI 3.0 contract — generate types from it, do not hand-write them)
3. https://intake.hellojade.ai/v1/vocabulary  (the live project_area / project_service vocabulary — fetch it, never hard-code it)

Rules that override your defaults:
- The base URL is https://intake.hellojade.ai and is configuration, not a constant. There is no http:// listener.
- Auth is the X-API-Key header. The key comes from the environment (HELLOJADE_API_KEY). It must never appear in source, a URL, a log line or an error message.
- Always send Idempotency-Key = "<our-namespace>:<our stable lead id>". Never a timestamp, never regenerated per attempt. 202 = new, 200 = duplicate with the same event_id; both are success.
- Retry only on 5xx, timeouts, and 429 (sleep at least Retry-After, then grow the wait with jitter; a 429 does not consume a delivery attempt). Never retry any other 4xx. A 422 means the body needs fixing.
- Do not send a "source" field; the key's registered label is the source. Do not send "extra". Send unmodeled fields at the top level; they are preserved.
- Rate limits: 600 requests/min per key (burst 101); 120/min per source IP (burst 31), applied before authentication.
- NEVER send a test lead with a real-looking name or phone. The only sanctioned test against production is a real key with an empty JSON body: POST {} must return 422 validation_failed, which proves the key works and stores nothing. For a live round trip, stop and ask me for a sandbox key.

Definition of done — run each check and report the observed status code, not an opinion:
1. Key check returns 422 — The §1 key check returns 422, not 401, against the key you will ship with.
2. A minimal lead returns 202 — A lead with first_name, last_name and phone returns 202.
3. A repeat returns 200 with the same event_id — The same lead sent twice with the same Idempotency-Key returns 202 then 200, with the same event_id, and your system records one send, not two.
4. The Idempotency-Key is namespaced and stable — It is prefixed with something only you use and does not change across retries — not a bare integer, not a timestamp, not regenerated per attempt.
5. A 422 surfaces every failing field — A lead missing all three required fields returns 422 and your code reports all three names, not just the first.
6. A 503 retries with backoff and loses nothing — Point at a dead host: the lead is retried with growing, jittered backoff and is never dropped.
7. A 422 does not retry — Retrying an unchanged 422 burns your rate limit and fixes nothing.
8. A 429 waits and does not spend an attempt — Sleep for Retry-After (a floor of one second), grow the wait on repeats, and do not count it as a delivery attempt.
9. The key appears in no log, error, trace or commit — Grep for it before you call the integration done.
10. An unmappable project_area is sent raw — Unrecognized values are stored and flagged, never rejected — send what your system calls it.
11. event_id is stored and request_id is logged — event_id against your lead record; request_id on every failure — that is what makes a support question answerable.
12. The base URL is https:// and is configuration — Nothing listens on port 80, and the host must not be a constant in the code.

Store event_id against our lead record and log request_id on every failure.

curl -s https://subscription.hellojade.ai/api/plans | head -c 400
# 200 application/json — a JSON array; each element has slug, name, amount_cents, interval, items[]

Read the public hellojade subscription plan feed and use it as the only source of plan data.

Source (fetch it live; do not paste it into the code): https://subscription.hellojade.ai/api/plans

What it is: a GET with no authentication returning a JSON array of published plans. Each element carries at least slug, name, customer, amount_cents, interval and an items array of {title, detail}. Treat unknown fields as data to preserve, not errors.

Rules:
- Read-only. There is no write API here for third parties; the checkout endpoints on the same host are for the hellojade.ai storefront only and are CORS-locked to it. Do not call them.
- GET /api/catalog is not public today (it answers 404 from production as of 2026-09-03); do not build on it.
- No rate limit is published for the feed. Fetch it once per build or cache it for at least five minutes at run time; do not poll it.
- Prices are amount_cents in USD per interval. Never format a price from a field you have not read.

Done when: a GET returns 200 with a non-empty array, your code parses every element without a hand-written field list, and it fails closed (no plan shown) when the feed is unreachable rather than showing a stale or invented price.

curl -i -X POST https://forms.hellojade.ai/v1/forms/$TENANT/contact \
  -H "X-API-Key: $FORMS_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{"form_key":"contact","email":"x@example.invalid"}'
# 400 missing_required → key + form resolve, nothing stored · 401 → key wrong · 403 → tenant mismatch

You are posting website form submissions to hellojade's forms endpoint for ONE tenant (a hellojade customer). This is a tenant integration, not a partner one: the key is issued to the customer and is scoped to their tenant slug.

Endpoint: POST https://forms.hellojade.ai/v1/forms/{tenant}/{form_key}
Headers: X-API-Key (from the environment, never in source or logs), Content-Type: application/json
Body: a flat JSON object of the form's fields (name, email, phone, message, plus whatever the form collects). Include page_url and referrer if you have them; campaign attribution (gclid, utm_*) is read from them.

Rules:
- {tenant} in the path must equal the key's tenant, or the answer is 403. Never guess a tenant slug; take it from configuration.
- Never fill a hidden honeypot field. A non-empty top-level "website" field is graded as a bot fill and delivers nothing.
- Both per-IP and per-tenant rate limits apply and answer 429; the numbers are not published. Retry on 5xx and 429 with backoff; never retry a 4xx.
- The ONLY sanctioned production probe is a body that names a real form key and fails required-field validation, for example {"form_key":"contact","email":"x@example.invalid"} → 400 missing_required. That proves the key and form resolve while storing, delivering and emailing nothing. 401 means the key is wrong; 502 or 404 means the form key did not resolve. Never send a plausible name and phone number as a test — real people are emailed on every accepted submission.
- The ops endpoints (/v1/leads, /v1/report, /metrics) are not public; they answer 404 through the edge. Do not build on them.

Done when: the probe above returns 400 missing_required (not 401/403/502), a real submission from the live form is confirmed by the customer's notification email, and the key appears in no log line or committed file.