Hubsite architecture

Immutable QR, dynamic payload

Each hubsite resolves through a stable short URL. The QR encodes that URL and does not change when you edit contacts, swap a PDF, or refresh a catalog. Measurement attaches to scans of that code, so physical assets stay valid for years.

Core sections

• Header: identity, optional media, profile type, up to three focus areas and three goals.
• Contacts: phone, email, chat apps, address, and custom fields with device actions.
• Links: social and web properties with recognizable icons and ordering you control.
• Tabs: documents and catalogs (tier-dependent), each with their own visibility.

Shared assets across hubsites

Every contact, link, document, and catalog item is defined once at account level. When you create or edit a hubsite, you select which assets to include. Change a phone number, update a PDF, or adjust a catalog price once, and every hubsite referencing that asset reflects the update immediately. This makes managing multiple hubsites operationally simple: each hub is an assembly of shared, always-current building blocks rather than a standalone copy.

Visibility model

Contacts, links, and tabs can each be public, limited to registered Yme.im users, password-protected, or locked to the owner. That granularity supports public menus with private pricing, or public branding with gated spec sheets.

Lifecycle controls

Beyond visibility, hubsites can be toggled active or inactive, limited to date ranges, or capped by maximum scan counts. Useful for events, limited campaigns, or phased rollouts.

Owned space

A hubsite is not a feed and not a rented attention surface. Visitors arrive in a distraction-free layout the owner controls. No competitor ads in the experience, no algorithm reordering the message. Contrast that with QR codes that drop users into social apps; see what is a hubsite and hubsite vs Linktree .