# Shared footer, assets and button sizes This contract applies to every email, in addition to its per-email contract. The footer and button default are authored once in src/emails/email-design.cjs and rendered by src/emails/email-chrome.cjs. Rebuild after changing the shared policy. Portable HTML remains a full email document with inline critical styling and no scripts or preview controls. ## User-approved footer data | Field | Value / source | Integration handling | | --- | --- | --- | | Mobile invitation | Take Built with you. Download the Built mobile app. | Natural-copy adaptation of the supplied reference. Keep secondary to the message action. | | Copyright | © 2026 Built Financial Technologies Inc. All rights reserved. | Reference year is centralized for deterministic drafts. In Laravel preserve the original shared footer’s date('Y') behavior if runtime year is desired; otherwise update copyrightYear once annually. | | Address | 1151 Walker Rde Ste 100 Delaware, United States | Supplied reference and API vendor/mail/html/footer.blade.php agree. Preserve the spelling; the older welcome view’s Walker Road/Dover/ZIP format conflicts and is not substituted. | | Phone | +233308040007 | tel:+233308040007. This is shared-footer contact data, not permission to replace specialized support numbers inside email bodies. | | Email | support@built.africa | mailto:support@built.africa. Do not replace merchant Reply-To or other headers. | | Google Play | https://play.google.com/store/apps/details?id=com.builtaccounting.app&hl=en | User-supplied exact application destination. Escape the ampersand as & in HTML attributes. | | App Store | https://apps.apple.com/gh/app/built-accounting/id1547855525 | User-supplied exact application destination. | No new body placeholders are required by the footer. All non-welcome extracts use the approved constant store destinations. Welcome retains its existing {{google_play_url}} and {{app_store_url}} aliases, now in the shared badge links instead of a repeated body section. Map those two aliases to the exact URLs above. This deliberately supersedes the old welcome Google Play search URL under the user’s new destination instruction; the catalog’s original-source evidence remains historical. ## Badge assets — required for sending | Asset | Published file | Default ready src | Original | | --- | --- | --- | --- | | Google Play | [google-play.png](../../assets/google-play.png) | cid:built-google-play | [google-play.webp](../../assets/google-play.webp) | | App Store | [app-store.png](../../assets/app-store.png) | cid:built-app-store | [app-store.webp](../../assets/app-store.webp) | The user supplied both WebPs. PNG conversion preserves their decoded artwork at 209 × 80 pixels; display is a proportional 128px width. Original WebPs are retained. Older hosted PNGs discovered in the API use different artwork and are intentionally not substituted. No new public hosting URL has been provisioned. CID is an attachment reference, not an automatically hosted image. Copy the PNGs into the consuming project and embed them in the message with matching CIDs, or replace the src values with the framework’s returned embedded-image references. In a Laravel Blade view, the native $message->embed(resource_path('emails/assets/google-play.png')) and equivalent app-store path can supply generated CID values. Replace the whole fixed src with that escaped Blade expression; simply attaching a normal file does not make an arbitrary CID work. Keep image paths trusted and server-owned. Alternatively host these exact PNGs at approved accessible absolute HTTPS URLs, validate host/path separately and replace both src attributes. Do not deploy relative preview paths or invent CDN filenames. Preserve the original left Built logo’s existing HTTPS/CID policy. The [asset manifest](../../email-assets.json) records files, CIDs, dimensions, alt text and destinations; release.json hashes the supplied assets for consumers to pin. Previews use local PNGs, and the workspace/open/ready-review views embed them for offline rendering. Ready HTML downloads retain the CID contract. A raw ready file opened directly in a browser may show alt text for CID images because it has no MIME attachments; that is not email-delivery validation. The selected-theme Ready-to-use HTML review is the intended browser inspection route. ## Variants and shared changes | Size | Desktop height | Text / line height | Horizontal padding | Mobile minimum | | --- | --- | --- | --- | --- | | sm | 32px | 14px / 20px | 12px | 44px | | md (default) | 40px | 14px / 20px | 16px | 44px | | lg | 52px | 16px / 22px | 24px | 52px | Change button.defaultSize in email-design.cjs and rebuild to update every email action. Existing body emitters keep calling button(label, key); they do not know padding values. An intentional one-off render can pass buttonSize: 'sm', 'md' or 'lg' to renderEmail. Unknown variants fail explicitly. Mobile media queries enlarge small/medium targets without restoring desktop’s old large appearance. Tables, inline padding/borders and cosmetics remain compatible with progressive email rendering; clients may vary. When copying generated HTML into another project, the sizes are already inline. To retain central updates there, adapt the same small button interface into that project’s native Blade partial/component; do not make production rendering depend on a moving staging URL. Pin a reviewed revision and regenerate/reintegrate deliberately. No React or new template framework is required. ## Text, optional sections and safety The build adds the same footer once to every text alternative, normalizing legacy trailing Built-only stubs. Welcome app aliases remain intact. Merchant/business sign-offs and transactional values stay in the body. Do not remove per-email optional sections, expiry instructions, financial data, headers or attachments while updating shared chrome. Preview store/contact actions are inert local explanation links. Sendable footer links use the approved stores and tel/mailto values; testing must not open them or send messages. The footer is not an additional primary transactional action: badges use separate classes, so code-only/report/informational emails still have no invented workflow button. Keep dynamic text escaped, URL validation separate, and string replacement one-pass if used. Native Blade remains the recommended integration. Browser screenshots, local PNG decoding and offline CID substitution do not prove Gmail, Outlook, iOS Mail or actual embedded-image delivery; test the integrated MIME message in target clients.