Heroku API tokens (legacy UUID)

• gitleaks 8.30.1
• trufflehog 3.97.4

Heroku's 2024-03-07 changelog (devcenter.heroku.com/changelog-items/2842) shows the pre-prefix token as a bare 8-4-4-4-12 hex UUID and states such tokens remain valid until regenerated. Heroku documents three generations of this one credential class, all live until regenerated: the bare UUID (granted before 2024-04-01), HRKU-<uuid> (41 characters, changelog-items/3175) and HRKU-AA plus 58 characters (65); the 41- and 65-character generations are documented widths, not undocumented variants, and belong to the current OAuth family (heroku-api-key, #209), not this contract. A UUID carries no marker of its own: it is structurally identical to a Heroku app, release or request id or any unrelated UUID, and Heroku's OAuth client secret and refresh token are UUID-shaped secrets too. So, like twilio-auth-token and datadog-api-key, the value is scored as policy and only beside a same-line heroku keyword: gitleaks 8.30.1's heroku-api-key rule (a case-insensitive heroku keyword, then an assignment operator, then the exact UUID) and trufflehog 3.97.4's heroku/v1 detector (keyword-gated on heroku) both corroborate that policy and never report a bare UUID unconditionally. The length twin rests on both tools' exact 8-4-4-4-12 UUID rules. An identifier-keyed UUID on a heroku line (HEROKU_APP_ID=<uuid>) is a public identifier #312 requires to stay clean; both keyword-gated peer rules flag it, and the product has excluded identifier-shaped keys since redact-secret#714 (known gap product-714, fixed). Uppercase hex and the 40-hex token in devcenter's authentication article are recorded as unresolved, never asserted either way (#232), and no legacy token can be newly issued. redact-secret#312 (PR #675) froze the same keyword-gated Medium-confidence shape on the product side.