The direct answer
Webhook endpoints belong to a single Stripe account, so a destination account starts with none and neither Customer Data Copy nor a subscription import creates them. MoveMRR can recreate the source account’s enabled endpoints on the destination as an opt-in step of the live run, copying the URL, subscribed events, API version, description, and metadata. Stripe never releases an existing signing secret, so every newly created endpoint receives a fresh whsec_ that must be re-deployed to the consumers behind that URL before events are trusted again.
Reviewed August 15, 2026 by the MoveMRR product team.
Migration behavior: Stripe Webhook Endpoints
When “Migrate Stripe webhook endpoints” is enabled on the project, the live run lists the endpoints on both accounts and recreates each enabled source endpoint the destination does not already cover, copying url, enabled_events, api_version, description, and metadata, and stamping a movemrr_source_webhook_id back-reference on the new object. Where the destination already has an endpoint at the same URL that covers only part of the source events, that endpoint’s event list is widened instead of creating a duplicate, so it keeps its existing signing secret and no event is delivered twice. Endpoints the seller had disabled are skipped rather than silently re-enabled on the buyer’s account, and matching is on the exact URL string—there is no domain rewriting, so an endpoint that should point at new infrastructure must be created there deliberately.
What the readiness review must verify
Compatibility is established from the actual Stripe objects, not from a page title. The project should surface every missing mapping, unsupported field, ambiguous state, and destination prerequisite before the live run.
- Both Stripe keys carry the extra webhook permission: read on the source key, write on the destination key.
- Every source endpoint URL is one the destination team actually controls and can deploy to.
- The consumers behind each newly created endpoint can be given a new signing secret at cutover.
- Existing destination endpoints are reviewed, because a same-URL endpoint has its event list widened rather than duplicated.
The primary failure mode to control
Signature verification failing after the cutover. Stripe issues a new whsec_ for every endpoint that is created, and a consumer still validating against the old secret rejects every delivery. The run’s Webhooks tab separates created, updated, skipped, and failed endpoints and names exactly which ones need the new secret, which is read from the destination Stripe dashboard—MoveMRR never receives or stores the secret value.
Stripe Webhook Endpoints: source-to-destination checks
| Check | Required evidence | If it fails |
|---|---|---|
| Key permissions | Webhook read on the source key and webhook write on the destination key | Key validation fails; regenerate the restricted key with the added scope |
| Endpoint coverage | The pre-run check lists every enabled source URL as covered or missing | Enable the option or recreate the endpoints manually before cutover |
| Signing secrets | Each created endpoint has an owner who will deploy its new whsec_ | Events are rejected by signature verification until the secret is deployed |
| Post-run diff | The reconciliation report reports covered rather than partial or missing | Add the missing events on the destination endpoint and re-verify |
A controlled workflow
- 1
Verify the first prerequisite
Both Stripe keys carry the extra webhook permission: read on the source key, write on the destination key.
- 2
Verify the second prerequisite
Every source endpoint URL is one the destination team actually controls and can deploy to.
- 3
Test representative examples
Use sandbox data that includes the difficult records, not only the happy path.
- 4
Control the primary failure mode
Signature verification failing after the cutover. Stripe issues a new whsec_ for every endpoint that is created, and a consumer still validating against the old secret rejects every delivery. The run’s Webhooks tab separates created, updated, skipped, and failed endpoints and names exactly which ones need the new secret, which is read from the destination Stripe dashboard—MoveMRR never receives or stores the secret value.
- 5
Reconcile after creation
Compare destination behavior with the approved source-state and monitor the next event.
Frequently asked questions
Can the webhook signing secret be migrated with the endpoint?
No, and no tool can do it. Stripe returns a signing secret exactly once, when an endpoint is created, and never discloses it again. Endpoints MoveMRR creates on the destination therefore have a new whsec_ that you read from the destination Stripe dashboard and deploy to your consumers. Endpoints that were merely widened keep the secret they already had.
What happens if the destination already has an endpoint at the same URL?
It is not duplicated. If the existing endpoint already covers all the source events, the source endpoint is skipped. If it covers only some of them, MoveMRR updates that endpoint with the union of both event lists, which preserves its signing secret and avoids delivering the same event twice.
Are disabled webhook endpoints recreated too?
No. An endpoint the seller had disabled is reported as skipped rather than recreated, because re-enabling it on the buyer’s account would resume deliveries the seller had deliberately stopped. Recreate it manually if the buyer wants it active.
Can I rehearse this before the live cutover?
Yes, in a sandbox project, which is free and unlimited. Note that sandbox seeding does not copy webhook endpoints into a sandbox, so create a couple of endpoints in the source sandbox by hand first; the run then exercises the same copy logic in Stripe test mode.