Webhooks FAQ

I created a user in Piano or Stripe but they are not in CoEditor Customers

Check the basics first

Open publication Settings and confirm webhooks were generated (Generate Base Webhook for Stripe; Piano Proxy then base webhook for Piano).
Confirm the correct API keys and secrets are saved (Stripe key; Piano Aid or token plus private key).
For Piano, verify the proxy URL in Piano’s admin UI still matches the URL shown in CRM—regenerating without updating Piano is a common break.

Timing

Webhooks are near-real-time but not instant. Wait a minute and refresh Customers. Heavy provider delays are rare but possible.

Where the record should appear

Stripe-driven billing identity usually lands under Customers and related Subscriptions once customer and subscription events flow.
Piano-driven identity follows the Piano events your publication subscribes to—some Piano event names are subscribed for routing but may not yet create or update every CRM screen. If Piano shows the user and CRM does not after a healthy setup, contact CoEditor support with the Piano user id and approximate time.

Sandbox vs live

Stripe test mode and live mode use different keys and webhook endpoints. Make sure the CRM publication uses the same mode as the Stripe dashboard where you created the customer.

Subscriptions look wrong or stale in CRM

Confirm customer.subscription.* style events are still on the Stripe base webhook (super admins only for base edits).
In Stripe’s dashboard, open the webhook endpoint CoEditor registered and check recent deliveries for failures (4xx/5xx).
For Piano access changes, confirm the proxy receives events and that Piano still sends the access / subscription event types you expect.

We subscribed to an event but nothing changed in CRM

CoEditor may accept an event (HTTP success) without updating every CRM view for that event type—especially for some Piano access events or Stripe charge events outside the core customer/subscription sync set.

Before assuming webhooks are broken:

Identify which provider event you expect (for example subscription updated vs charge succeeded).
Check whether the change should affect Customers, Subscriptions, or another area.
If setup in Settings is correct and the provider shows successful delivery, contact support with the event type and a sample id from Stripe (evt_…) or Piano.

Piano only lets us configure one webhook URL

That is expected. Use the Piano proxy URL as that single destination so CoEditor can decrypt traffic and optionally forward copies elsewhere.

Do not try to register a second native Piano URL unless Piano’s product UI explicitly allows it for your contract.

Can we use Piano as a proxy for more than one Stripe webhook?

Piano’s single-URL limitation is about Piano-originated events. Stripe webhooks are configured separately through CRM Settings and Stripe’s own endpoint list. CoEditor registers Stripe endpoints per publication; use Add Webhook or Import from Stripe when you need additional Stripe listeners beyond the base webhook.

If your question is about fan-out to multiple non-CoEditor systems from Piano, the proxy forwarding behaviour described on Piano proxy is the relevant pattern.

Digital products / ebooks are not showing in CRM

Product and entitlement sync depends on which provider owns the catalogue and which events your publication subscribes to. Start with Integrations and confirm both webhooks and product-related credentials are complete in Settings.

If webhooks are healthy but a specific SKU or ebook still does not appear, send support the product identifier and provider (Stripe vs Piano).

When to contact CoEditor support

Gather:

Publication name and id
Provider (Stripe or Piano) and environment (test vs live)
Approximate timestamp and user / customer / subscription id
For Stripe: a recent event id from the Stripe webhook delivery log if available

Engineering runbooks and handler-level debugging live in internal developer documentation—not in this customer documentation set.