Zintara integration secret storage: separate API access from webhook verification

Define the decision

An API key authorizes calls into Zintara. A webhook signing secret lets a receiver authenticate outgoing notifications. They have different purposes and should not be substituted for one another or shared across unrelated consumers.

Work through the procedure

1. Inventory each secret, owner, purpose and rotation process without recording its value.
2. Store values in protected server-side configuration or an approved secret store.
3. Restrict deployment and log access.
4. Redact Authorization and signature-related diagnostics as appropriate.
5. Test recovery and rotation using controlled credentials.

Worked example

The following is a synthetic example for this procedure, not a customer result or performance benchmark.

Secret inventory labels:
CRM reader API key → leads:read consumer
Reply receiver signing secret → raw-body HMAC verification
Inventory contains owners and locations, not plaintext values
Browser bundle: neither secret belongs here

Read the result

Keeping distinct secrets makes revocation targeted. A frontend environment variable exposed to the browser is not secret simply because its name contains SECRET.

Check before moving on

1. Search built client assets and logs for accidental exposure using safe local checks.
2. Remove obsolete values after a verified rotation.

Limits and next action

If a value has been exposed, rotate it and inspect its use rather than only deleting the visible copy. Do not paste production secrets into examples, support tickets or repositories.

Source: Zintara product context