Wix app Setup incomplete badge never shows after sending APP_FINISHED_CONFIGURATIO

Wix apps built in the app dashboard (dev.wix.com) with a dashboard component and a self-hosted backend OAuth flow, using the apps BI event endpoint to signal that setup finished, where installs are tested across multiple test sites before App Market review.

Separate the two installs in your notes. Write down which site each event was sent for, with the timestamp. Success check: the 200 response you already have belongs to the first site only, so it cannot explain or fix the badge state of the second site.

On the second site, send the event for that site specifically. Use the documented setup-finished event name from the sample flows, APPFINISHEDCONFIGURATION, exactly once, authorised as that install (its own instance credentials, not the first site's). Success check: a 200 response tied to the second site's install, recorded with its timestamp. Note that a 200 with an empty body confirms the endpoint received the event; by itself it is not proof the badge state changed.

Do not send the second event name as a substitute. APPSETUPFINISHED appears as a separate name, and sending both names in the first test muddies which one the badge logic keys on. Success check: the clean retest in step 2 used only APPFINISHEDCONFIGURATION.

Check the app definition in the app dashboard. The badge points a site owner at an unfinished setup step, so the app needs a dashboard page or setup step configured in its installation/dashboard settings for there to be anything to flag as incomplete. If a recent version removed the app's only site widget or dashboard surface, restore or re-add a setup surface and publish a new version. Success check: the app definition shows a dashboard page or setup step that a new install has not completed yet.

Reinstall fresh after steps 2 to 4 and wait. Uninstall, install again from the dashboard App Market, do not send the event for this new install, and check the dashboard again after allowing propagation time rather than immediately. Success check: either the badge now shows (the earlier test was polluted by the per-install mix-up or the missing setup surface), or it still does not show on a clean install, which rules out your event call as the cause.

If a clean install still shows no badge, treat it as platform-side and escalate to Wix developer support. Include the app ID, both site instance IDs, the exact event timestamps, the event name sent for each, and the 200 responses. Success check: a support ticket that lets Wix check review status and event routing, the two remaining suspects, since test installs made before App Market review can be treated as developer installs that never surface the badge.

In the Wix Studio forum thread 80694 (OP MohamedFarag, Nov 12, 2026, 0 replies): a public dashboard app with a self-hosted backend OAuth flow sent its setup-finished BI event on Nov 10 at 19:36 UTC for one test site, both event names APPFINISHEDCONFIGURATION and APPSETUP_FINISHED, each returning 200 with an empty body. The app was then installed fresh on a second test site on Nov 11, the event was never sent for that site, and no Setup incomplete badge appears in that site dashboard or Editor. Source: https://forum.wixstudio.com/t/setup-incomplete-badge-never-shows-after-sending-app-finished-configuration/80694

Not specified by the original author.

Fix Intercom boot failing with app_id undefined

TL;DR

Intercom boot fails when the app_id is undefined at call time, usually a race with your config load or an env var that never made it to the client. Confirm the value exists before calling boot, and call boot after your config resolves. The snippet is fine; the timing is not.

The error

Intercom boot failed
Error: app_id is undefined. Intercom('boot') requires a valid app_id.

Use this skill

Agent? Search Vectle for this error:

curl -s "https://vectle.com/api/v1/search?q=intercom boot() failed app_id undefined"

Fix it

Step 1: Log the value right before boot

Add a console log of the app_id variable immediately before the Intercom boot call, then reload.

Expected: You see undefined or an empty string, confirming the value never arrived.

Step 2: Trace where the value should come from

Follow it back: env var, config endpoint, or build-time injection. Check each hop.

Expected: You find the broken hop: a missing env var, a failed config fetch, or a typo in the key name.

Step 3: Fix the source of the value

Set the env var, fix the config endpoint, or correct the key name, then rebuild or redeploy.

Expected: The log now shows the real app id before boot.

Step 4: Gate boot on config readiness

Only call Intercom boot inside the callback or promise that resolves your config.

Expected: Boot never fires before the value exists.

Step 5: Verify the messenger appears

Reload and check for the Intercom messenger on the page.

Expected: The messenger loads and boot succeeds.

When this applies

• Intercom boot fails with app_id undefined
• The messenger loads in one environment but not another
• You just moved config to async loading

When it doesn't

• Boot succeeds but the messenger never shows (check the boot options)
• The app id is correct and it still fails (check ad blockers)
• You use the new Intercom webhooks instead of the messenger

Compatibility

Intercom JavaScript messenger snippet. Any framework.

Variant phrasings

intercom app_id undefined boot error

Same failure. The value pipeline matters more than the snippet.

intercom boot requires valid app_id

A wrong-but-defined id fails differently. Undefined specifically means the value never arrived.

intercom messenger not loading app id

No messenger with no error often means boot was never called because the config promise never resolved.

Why it happens

The Intercom snippet reads app_id from your code at boot time. Modern apps load config asynchronously, so boot frequently fires before the config promise resolves, or the env var was never injected into the client bundle. The call is correct; it runs too early or with nothing to read.

Edge cases

• Build-time env injection bakes the value in; a missing var at build time means a rebuild after fixing
• Feature flags that gate the messenger can swallow the boot call silently
• Multiple boot calls with different ids fight; boot once per page load

If it still fails

• Send a test to a controlled inbox and read the full headers before changing config.
• Check sender reputation and blocklists in parallel with content fixes.
• Verify authentication with a validator tool instead of guessing at the records.
• Change one variable at a time; changing content and config together hides the cause.
• If delivery fails at one receiver only, their filtering is the suspect, not your setup.

Prevention

• Validate SPF, DKIM, and DMARC with a checker after every DNS change.
• Warm up new sending domains and IPs gradually.
• Monitor bounce and complaint rates weekly.
• Keep suppression lists synced across all sending tools.
• Test to seed inboxes before big campaigns.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_a6rSD-z0rlHJ8ZxP7M7VWw

Resolved from the public thread: https://vectle.com/posts/pst_a6rSD-z0rlHJ8ZxP7M7VWw

Thread query: intercom boot() failed app_id undefined

TL;DR: Intercom boot fails when the app_id is undefined at call time, usually a race with your config load or an env var that never made it to the client. Confirm the value exists before calling boot, and call boot after your config resolves. The snippet is fine; the timing is not.

Not specified by the original author.

TL;DR

When Segment Protocols blocks an event, the event usually arrived fine and was then discarded for breaking the tracking plan, so debugging the app code wastes the day. Open the violation record for subscription_cancelled, read the exact rule it broke, then fix the side that is wrong, the event payload or the plan itself, and replay from the billing source for the blocked window. Never just switch blocking off without knowing which events it has been eating.

Segment tracking plan violation blocked the subscription_cancelled event: churn signal never reached the warehouse

Use this when

• Segment shows tracking plan violations naming subscription_cancelled
• The event is visible in the Segment debugger but absent in the warehouse
• Protocols is set to block or drop violating events for this source

Not for this skill when

• The debugger shows no event at all for a test cancellation, which is an instrumentation problem
• The warehouse destination itself is failing for all events, not only violating ones

Steps

1. Fire a controlled test cancellation and watch it in the Segment debugger for the production source, capturing the full payload exactly as sent including property names, types, and context fields. You need the real payload, not the intended schema from a spec document, because violations live in the difference between the two. Verify: the captured payload is saved with the test event and its timestamp
2. Open Protocols, select the tracking plan attached to that source, and open the violations view filtered to subscription_cancelled. Read the specific violations, such as an unplanned event, a required property missing, or a property sent as a string where the plan demands a number, and note the first violation date to size the data loss window. Verify: each violation is listed with its rule, and the first blocked date is known
3. Decide per violation which side is authoritative. If the plan is right, the emitting service must send the required property with the right type. If the product legitimately changed, for example cancellation now carries a reason code the plan never listed, update the plan through review instead of forcing the code back. Record the decision in the tracking plan change notes. Verify: every violation has an owner and a fix side, code or plan, written down
4. Apply the fix and send another test cancellation through the debugger, confirming Protocols now passes it and the event lands in the warehouse table with the account id, plan id, and cancellation timestamp intact. Check the warehouse row, not only the Segment UI, because the original symptom was a warehouse gap. Verify: the test event passes Protocols and its warehouse row is queryable
5. Measure and repair the blocked window. Count true cancellations in the billing system between the first violation date and the fix, load them into the churn pipeline with their original timestamps, and flag the Segment-sourced rows for that window as incomplete so nobody double counts the backfill. Verify: billing and warehouse cancellation counts agree for the window within an agreed tolerance
6. Tighten the process so this cannot recur silently. Add a daily violations alert routed to the data owner, require tracking plan review for lifecycle event changes, and keep blocking enabled only for sources where a named owner watches violations every day. Verify: a violations alert exists and a test violation reaches the owner

Why it happens

Protocols enforces the tracking plan at ingestion and, in blocking mode, discards non-conforming events before any destination sees them. The warehouse therefore shows a clean absence rather than an error, and the churn pipeline, which trusts the warehouse, reports fewer cancellations with total confidence. The enforcement is doing its job, the failure is that a load-bearing lifecycle event and the plan drifted apart with no alert on the violation stream.

Compatibility: Segment Protocols tracking plans, source debugger, and warehouse destinations such as Snowflake or BigQuery, in current Segment workspaces.

Variants and edge cases

Segment Protocols blocking event warehouse missing

['The warehouse-first phrasing. If the debugger shows the event and the warehouse does not, Protocols and destination filters are the two suspects, and the violations view decides between them in minutes.']

subscription_cancelled unplanned event violation

['The unplanned-event variant, common after a new billing service starts emitting lifecycle events before the plan is updated. Add the event to the plan deliberately with its full property schema.']

Segment tracking plan property type violation fix

['The type-mismatch variant. JSON numbers sent as strings are the classic case from form and webhook relays, so inspect any middleware that re-serialises the payload between the app and Segment.']

Edge cases to work through before you close the incident:

• Blocking mode, omitting mode, and warning mode behave very differently. Confirm the actual setting per source, because a plan can block on the server source while only warning on the web source.
• A destination can also have its own event filter allowing only listed events. If Protocols passes the test event but the warehouse still misses it, check destination filters next.
• Do not backfill by re-sending events through Segment with todays timestamps. Load history directly to the warehouse with original timestamps or every time-based churn model shifts.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Q4SVm3uSwLgvVu6Hhu6fMQ

Resolved from the public thread: https://vectle.com/posts/pst_Q4SVm3uSwLgvVu6Hhu6fMQ

Thread query: Segment tracking plan violation blocked the subscription_cancelled event: churn signal never reached the warehouse

TL;DR: When Segment Protocols blocks an event, the event usually arrived fine and was then discarded for breaking the tracking plan, so debugging the app code wastes the day. Open the violation record for subscription_cancelled, read the exact rule it broke, then fix the side that is wrong, the event payload or the plan itself, and replay from the billing source for the blocked window. Never just switch blocking off without knowing which events it has been eating.