Skip to main content
Update an existing store’s name, status, or configuration settings. Only fields included in the request body are updated; omitted fields remain unchanged.
Authentication: API Key (owner or admin role required)
This endpoint does not manage webhook configuration. If a webhookSettings field is sent in the request body it is silently ignored and the response includes a top-level warnings array; other fields update normally and the call returns 200. Use add-webhook, update-webhook, and remove-webhook to configure webhooks, and GraphQL Store.storeWebhooks to list them.

Request Body

Notification Settings

Two categories with different write permissions: Merchant-writable (✅ accepted via this endpoint): Platform-managed (🔒 read-only via merchant API; managed by PANCAKE platform):
If your notificationSettings payload includes any platform-managed field (the read-only email* keys above, or the legacy notifyPayoutCompleted / notifyPayoutFailed keys — payout result emails are always delivered and have no toggle), the server silently drops it and returns a 200 response with a warnings[] entry listing the dropped keys. emailUpcomingCharge and emailTrialEnding are not among them: both are accepted and applied, and the response carries no warnings for them. To toggle any other customer email, contact PANCAKE platform support.

Checkout Settings

Checkout Theme Settings (applies to both light and dark):

Partial Update Semantics

Both settings objects support partial updates. Each sub-field follows these semantics: Setting the entire object to null (e.g., "notificationSettings": null) clears all fields in that settings group. "notificationSettings": null clears exactly what this endpoint is allowed to write: every notify* toggle plus emailUpcomingCharge and emailTrialEnding (they all read back as their true defaults). The platform-managed email* toggles are left untouched — a merchant can neither write them nor reset them by clearing. The store’s notification recipient list is untouched too: recipients are managed exclusively through the three store-notification-recipient endpoints.
Clearing switches a silenced customer reminder back on. A store that set emailUpcomingCharge or emailTrialEnding to false reads it back as true after one "notificationSettings": null, and its buyers start receiving that reminder again.Send a partial update instead — only the keys you actually want to change:

Example Request

Success Response (200)

Response Fields

Same as Create Store response fields. Verification-managed (🔒 read-only via this endpoint; returned for reference only):
supportEmail and website cannot be set through this endpoint. Each is written automatically once the merchant completes support-email verification or product-domain verification for a store with production enabled (prodEnabled: true). A request that includes either field returns 200 with the store unchanged and no warnings entry — the field is dropped silently.

webhookSettings Compatibility Warning

If a webhookSettings field is sent in the request body, it is silently ignored and the response includes a top-level warnings array. The data.store object is unaffected.

Errors

Retry policy: Never retry 4xx — fix the request and resubmit. Retry 5xx with exponential backoff (start 5s, max 3 attempts).