Customer support infrastructure

Works after HyoNova sets up its Meta connection and your company connects its own WhatsApp Business number; until then it shows 'Not configured'.

This page is for HyoNova's own platform operators. It covers the platform side of HyoNova Support — the customer support product that companies use with their own customers. It is not about Support cases, the place where HyoNova staff help organizations.

What the platform provides#

Until the platform requirement is met, companies see Not configured on those channels. Nothing reports a channel as connected without real stored facts.

Set up the Meta app#

In Control Center › Providers › Messaging, configure the Meta app that HyoNova uses for every company:

• the app id and app secret of HyoNova's Meta app;
• the Facebook Login for Business configuration id, which names the permissions companies grant (WhatsApp business management and messaging, Pages list, metadata and messaging, Instagram messaging, business management);
• the webhook verify token;
• the Graph API version.

Secrets are written to the platform secret store, never returned to the browser. Test proves that the app id and secret belong together with one server-side call to Meta, and records the result. The app's webhook must point at HyoNova's support webhook endpoint for Meta and subscribe to messages and message status updates.

The platform Meta app is the only Meta configuration operators manage. Companies' own business tokens are stored per channel in the secret store and are never visible in Control Center.

Watch the infrastructure#

Control Center › Operations › Customer support infrastructure shows metadata only — never customer message content:

• the Support module's state (implemented, test stage, availability);
• the messaging provider's configuration state and last test;
• webhook receipts per provider for the last 24 hours: received, processed, failed and ignored, plus those still pending, and the time of the last one;
• support jobs (outbound deliveries, webhook processing, maintenance) by type and status, with the oldest waiting job;
• webhook queue deliveries by status;
• channels across all companies by type and status, with the last webhook, inbound and outbound times.

Repair actions#

Both actions need operations management permission, a recent step-up sign-in and a written reason, and both are recorded in the platform audit log.

• Replay receipts re-processes failed or ignored webhook receipts since a given time — for example after a company reconnects a channel whose messages were refused. Up to 500 receipts per run. Receipts whose raw payload was already removed cannot be replayed.
• Retry jobs re-queues support jobs that failed in the last 7 days, up to 500 per run.

Retention#

Raw provider webhook payloads are removed after 7 days; the normalized messages stay in the company's records. Receipt records themselves are removed after 90 days.