Authentication states
Overview
Hubble supports blocks for customers who arrive via secure email links to Shopify account pages, most commonly the Order Status page. In this pre‑authenticated state, Shopify restricts many customer fields from the Customer Accounts API. Hubble handles this by showing safe general content until the customer logs in, at which point personalized content can display.
Block types in a nutshell
No display conditions. Ideal for universal messages and banners.
Can define one optional Default setting as a fallback.
Can add multiple additional settings with conditions that resolve when met.
Purpose‑built blocks with unique features and a separate creation flow. Some can also be used with conditions.
Using variables with safe defaults
You can reference variables like
{{ customer.first_name }}in any block type.In pre‑auth, some fields are not available. Use the variable defensively by adding defaults:
Example: Hello,
{{ customer.first_name | default: "buyer" }}!
Apply this pattern when using data that is not pre-auth to avoid empty values conditions that won't match. This keeps content clear for guests and personalized for logged‑in customers.
What customers see
Pre‑authenticated customers
Can open account pages via secure email links, commonly the Order Status page.
Shopify limits access to many fields in this state.
Hubble skips auth‑dependent conditions inside Dynamic blocks' settings, if no other available condition exists it shows the Default setting if present. Static blocks render as usual.
Authenticated customers
After logging in, all fields are available.
Dynamic block conditions can match and display personalized content.
How matching via Conditions works today
Static blocks
Always safe to show as they aren't used with Conditions.
Dynamic blocks
Pre‑auth: Auth‑dependent conditions are skipped. If the Dynamic block doesn't find a matching setting available and it has a Default setting, Hubble shows it when defined.
Note: There is no extra configuration for pre‑auth behavior at this time. The “default” behavior above is built‑in.
Auth: All conditions are evaluated normally. If none match, the Default setting acts as fallback when defined.
Best practices
Always include a useful Default in dynamic blocks
This ensures guests see relevant content even when auth-data is unavailable.
Keep defaults non‑sensitive
Reserve sensitive or personalized content for authenticated views.
Use defensive text with variables
Provide defaults like
{{ customer.first_name | default: "buyer" }}to avoid empties in pre‑auth.
Leverage static blocks for universal messages
Shipping promos, policy notices, and storewide CTAs are ideal candidates.
Testing your setup
Create a test order via normal checkout.
Open the Order Status link from the confirmation email in an incognito window to simulate pre‑auth.
Confirm that static blocks and dynamic block Defaults appear as expected.
Log in to confirm personalized conditions render for authenticated customers.
References
Last updated