Crisp support chat is managed as a platform-level integration. You configure one Crisp Website ID in Admin, then every eligible ZShip frontend loads the chatbox automatically and writes its app_key into Crisp session data.

Why no new Worker

Crisp already stores the conversation history and inbox state. ZShip only needs to store the integration config:

• enabled or disabled
• Crisp Website ID
• all-projects or selected-projects targeting
• optional Crisp inbox shortcut

That config lives in node1-auth-service under t_admin_setting.crisp_integration_config. A separate Worker would add another deploy target without owning any unique durable data.

Admin setup

1. Open Admin → Crisp Chat (/crisp-settings).
2. Enable Crisp and paste the Website ID from your Crisp dashboard.
3. Keep All projects selected if every current and future app_key should use the same inbox.
4. Save. New apps based on the ZShip template do not need a separate Crisp script.

Use Selected projects only when you want a gradual rollout or need to keep specific tenants off chat.

Frontend behavior

The ZShip templates call node1-auth-service for the current app's public Crisp config. If enabled, the template injects Crisp and sends:

• app_key
• project title and domain
• user email or guest ID when available
• a zship-app:{app_key} Crisp segment

This is what lets one Crisp inbox handle multiple ZShip projects while keeping conversations filterable by tenant.

Do we store chat records in D1?

No, not by default. D1 stores only configuration. Crisp remains the source of truth for messages, assignment, inbox state, and transcripts.

Add a Crisp Webhook and a new storage path only if you need local compliance retention, analytics, or support automation that cannot be handled inside Crisp.

Crisp dashboard notes

If the same Crisp Website ID is used on multiple domains, review Crisp's chatbox security settings. In particular, domain-locking must match the domains where your ZShip apps run.