Managing Webhook and Partner Secrets on a Two-Sided Marketplace

A seller-side partner reports receiving a webhook that references order data they don't recognize. Before you can tell them it's a false alarm or a real problem, you need to know which signing secret produced that call, whether it's scoped to that partner alone, and how quickly you can rotate it without breaking every other integration that shares infrastructure with it.

Every new partner, on either side of a transaction, typically means a new API key, a new webhook secret, and sometimes a new set of payment credentials for that specific integration. A marketplace that's onboarded a hundred partners over a few years often has far more live credentials than anyone can name from memory, simply because growth never came with a decommissioning process attached.

Doppler lets you organize partner credentials into clearly separated projects, buyer-side integrations in one, seller-side in another, so a search for a specific partner's secret doesn't require scrolling through every credential the platform has ever issued. For a marketplace onboarding new partners regularly, that organization matters as much as encryption does.

For a marketplace processing high transaction volume, Vault's transit engine can handle signing and verification of webhook payloads without ever exposing the raw signing key to the application code that uses it. That separation limits the blast radius if an application server is compromised, since the key used to sign requests never has to leave Vault itself.

Rotate that partner's signing secret immediately, then check whether the same secret or infrastructure is shared with any other partner integration before declaring the incident contained. Confirm with the reporting partner once the new secret is in place, and document the timeline in case the same issue resurfaces with a different partner later.

When a partner reports a suspicious webhook call:

1. Rotate that partner's signing secret immediately, before deciding whether the call was a false alarm.
2. Check whether the same secret or infrastructure is shared with any other partner integration.
3. Verify each request's signature against that partner's specific signing secret, and reject any mismatch instead of logging it for later.
4. Confirm with the reporting partner once the new secret is in place.
5. Document the timeline in case the same issue resurfaces with a different partner later.

When a partner integration is replaced or a partner leaves the marketplace, the old integration's signing secret and API key often get left active simply because deactivating them wasn't part of the offboarding checklist. Months later, that dormant credential is still technically valid, sitting unused until someone finds it, either a security reviewer doing a periodic audit or, worse, someone who shouldn't have it.

Build credential deactivation into your partner offboarding process the same way you'd build it into a client offboarding process, and periodically review every active signing secret against your current list of live partner integrations to catch anything that should have been retired already.

A seller-side partner ends their relationship with the marketplace. Offboarding them properly means more than removing their listing: revoke their API key, deactivate their webhook signing secret, and remove any stored payment credentials tied to their account, in that order, checking each one against your active credentials list afterward to confirm nothing was missed.

A marketplace that's grown through years of partner onboarding without a matching offboarding discipline usually finds, when it finally audits its credentials, dozens of still-active secrets belonging to partners who left long ago. Building offboarding into the same checklist used for onboarding, rather than treating it as a separate, less urgent task, is what prevents that pileup from happening again.

A marketplace's business development team is usually the first to touch a new partner relationship, collecting business details and getting an integration started. That team rarely needs, and shouldn't have, direct access to the payout API credentials that actually move money once the integration goes live.

Structure access so onboarding and payout operations are separate roles in your secrets tool, not just separate job titles. A partner-facing hire who leaves the company shouldn't be a credential rotation event for anything that touches settlement, and someone in payout operations shouldn't need to comb through onboarding notes to find a partner's live signing secret.

This split matters more as the marketplace grows past its first handful of partners, when the people managing relationships and the people managing money stop being the same two or three founders who trust each other by default.