docs(config): document platform-name defaults for card tokenization 2FA copy - #927
Conversation
…FA copy Verification messages now default to the platform's name for the display name, sender name, subject and body when a platform has not overridden them (webdev#34633). Say so on each field. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011dU4iNZ2goV3EnNZHso67R
|
The latest updates on your projects. Learn more about Vercel for GitHub. 2 Skipped Deployments
|
|
Preview deployment for your docs. Learn more about Mintlify Previews.
|
This stack of pull requests is managed by Graphite. Learn more about stacking. |
✱ Stainless preview builds for gridThis PR will update the cli go kotlin openapi php python ruby typescript ⏳ grid-typescript studio⏳ grid-openapi studio⏳ grid-ruby studio⏳ grid-kotlin studio⏳ grid-go studio⏳ grid-python studio⏳ grid-php studio⏳ grid-cli studio⏳ These are partial results; builds are still running. This comment is auto-generated by GitHub Actions and is automatically kept up to date as you push. |
Greptile SummaryDocuments the service-computed defaults for card-tokenization 2FA branding and message copy.
Confidence Score: 4/5The PR appears safe to merge after a non-blocking clarification of how The generated contracts remain synchronized and no behavioral or schema-shape defect was found; the only concern is documentation ambiguity that could cause integrators to mistake an illustrative substitution for supported input-template syntax. Files Needing Attention: openapi/components/schemas/config/CardTokenization2FAEmailConfig.yaml, openapi/components/schemas/config/CardTokenization2FASmsConfig.yaml
|
| Filename | Overview |
|---|---|
| openapi/components/schemas/config/CardTokenization2FAConfig.yaml | Documents the platform-name fallback and its use in generated authentication copy. |
| openapi/components/schemas/config/CardTokenization2FAEmailConfig.yaml | Documents email defaults, but the {displayName} notation is ambiguous beside the prohibition on template variables. |
| openapi/components/schemas/config/CardTokenization2FASmsConfig.yaml | Documents the SMS fallback default using the same unexplained placeholder notation. |
| openapi.yaml | Updates the generated root contract consistently with the modular schema changes. |
| mintlify/openapi.yaml | Updates the generated Mintlify contract consistently with the source schemas. |
Prompt To Fix All With AI
### Issue 1
openapi/components/schemas/config/CardTokenization2FAEmailConfig.yaml:35-37
**Ambiguous displayName placeholder**
The description says template variables are unsupported, then expresses the default using `{displayName}`. The subject and SMS descriptions use the same unexplained notation. This makes it unclear whether integrators may include `{displayName}` in configured copy or whether it only illustrates a value substituted by the service. Please clarify the substitution and its fallback to the platform name.
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.Reviews (1): Last reviewed commit: "docs(config): document platform-name def..." | Re-trigger Greptile
| a controlled text and HTML template; arbitrary HTML and template variables | ||
| are not supported. | ||
| are not supported. Defaults to "Use this code to finish adding your | ||
| {displayName} card to your wallet." |
There was a problem hiding this comment.
Ambiguous displayName placeholder
The description says template variables are unsupported, then expresses the default using {displayName}. The subject and SMS descriptions use the same unexplained notation. This makes it unclear whether integrators may include {displayName} in configured copy or whether it only illustrates a value substituted by the service. Please clarify the substitution and its fallback to the platform name.
Prompt To Fix With AI
This is a comment left during a code review.
Path: openapi/components/schemas/config/CardTokenization2FAEmailConfig.yaml
Line: 35-37
Comment:
**Ambiguous displayName placeholder**
The description says template variables are unsupported, then expresses the default using `{displayName}`. The subject and SMS descriptions use the same unexplained notation. This makes it unclear whether integrators may include `{displayName}` in configured copy or whether it only illustrates a value substituted by the service. Please clarify the substitution and its fallback to the platform name.
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

Reason
With lightsparkdev/webdev#34633, card-tokenization verification messages default to the platform's name instead of "wallet" and "Lightspark" when a platform has not set
cardTokenization2faConfigfields. Integrators reading the spec should know what they get without overriding anything.Overview
Description-only changes on
CardTokenization2FAConfig,CardTokenization2FAEmailConfig, andCardTokenization2FASmsConfig:displayNamedefaults to the platform's name and drives the default sender name, subject, email body, and SMS fallback body. Each of those fields now states its default. No schema shape changes.Test Plan
make buildandmake lintpass. Lint output shows only pre-existing informational and warning findings on unrelated schemas.🤖 Generated with Claude Code
https://claude.ai/code/session_011dU4iNZ2goV3EnNZHso67R