Integration security

• Use TLS for every API and webhook connection; validate hostname and certificate chain.
• Keep secrets in a managed secret store and expose them only to the calling workload.
• Use separate test/live keys and separate keys per service so compromise has a bounded blast radius.
• Apply the minimum scopes, IP allowlists and practical expiries.
• Never log Authorization headers, refresh tokens, webhook secrets or unredacted report bodies.
• Encrypt retained subject, report and dispute data; restrict access by job function.
• Forward request IDs, authentication failures, key changes and webhook anomalies into monitored audit systems.

Responses set X-Content-Type-Options: nosniff, X-Frame-Options: DENY, Referrer-Policy: no-referrer and a restrictive Content-Security-Policy. These protect the API response surface but do not replace controls in your own dashboard or webhook receiver.

1. Revoke or rotate the exposed API key or webhook secret immediately.
2. Stop the affected workload if it may continue leaking data.
3. Search audit and usage records by prefix, request ID, IP, route and time window.
4. Assess subject/report data accessed or modified and preserve evidence.
5. Issue narrowly scoped replacement credentials and monitor their first use.
6. Follow organisational notification and legal response requirements.

Query credit only for an authorised business purpose, disclose it accurately in the inquiry, and retain only what is necessary. A username alone is not sufficient identity verification for a privacy or dispute request.