Security and Compliance

This guide states the security obligations of the integrator: what you must protect, how you must protect it, and what you must do when protection fails. The binding requirements are in the Partner Security Requirements; this guide is the working walkthrough of them, and where the two differ, Partner Security Requirements governs. It is an integration guide, not legal advice.

The division of responsibility

The Platform secures its side: your key reaches only your account's resources (Authentication and Authorization), and traffic is encrypted in transit. Your integration secures everything on your side of the call: the key's custody, your systems' behavior, the data you keep. That is where breaches actually happen, and it is the part this guide governs.

Key custody

Your API key is a full credential for its scope. Custody rules

1. Store keys in a secrets manager, injected at runtime. Never in source control, container images, configuration files committed anywhere, tickets, documents, or chat.
2. Use keys only from server-side systems you control. A key in a browser, a mobile app, or a desktop tool you distribute is a published key.
3. Give every key a purpose and an owner in your own records, and keep the set small: one per system that needs it, not one per developer.
4. Limit who and what can read each key inside your organization, and review that access when people change roles or leave.
5. If a key's value appears anywhere it should not: a log line, a screenshot, an email: treat it as compromised: revoke it, issue a replacement, and review what the old key did while exposed. See the rotation walkthrough under Secret rotation below.

Transport security

• Call the API only over HTTPS at https://www.aapawz.com/api, with certificate verification enabled. Never disable TLS validation to make a call succeed; a call that requires broken validation is a call to the wrong place.
• Keep your own systems' TLS current: supported protocol versions and ciphers: both for your API calls and for your webhook endpoint, which receives Platform data and must protect it the same way.
• Reject and log any attempt to make your integration send its key or Platform data to an unexpected host. Your integration has exactly one Platform host; anything else is wrong by definition.

Webhook signature verification

Your webhook endpoint trusts the Platform only after verification, never before

1. Verify the signature on every delivery, over the exact bytes received, against your endpoint's signing secret, using a constant-time comparison, and check the delivery timestamp against replay: the full procedure is in Webhooks, and the payload definitions are in Webhook Event Schemas.
2. Process nothing from an unverified delivery. An endpoint that skips verification "temporarily" is an unauthenticated write interface into your order system.
3. Keep the signing secret with the same custody as an API key, and rotate it when personnel or vendors with access to it change.

Secret rotation

Rotate keys and signing secrets on a schedule, and immediately on suspicion

1. Issue or request the replacement credential.
2. Deploy it to every system that uses the old one; confirm calls succeed under the new credential.
3. Revoke the old credential and verify it now returns 401.
4. Record the rotation: date, reason, who performed it: in your own security log.

Rotation mechanics and any overlap windows are specified in the API Key Management and Rotation Policy and Authentication Endpoints. A rotation that causes an outage was rehearsed too late; rehearse it when nothing is wrong.

Data minimization and protection

• Collect and keep the minimum. Your integration needs the Platform data its declared purpose requires: and no more. Buyer data in particular: keep what fulfillment, returns, and your legal records require, and delete the rest on the schedule the Data Use, Retention and Deletion policy sets.
• Protect what you keep with the controls Partner Security Requirements requires: encryption at rest, access limited by role, audit logging of reads and exports, and deletion that reaches backups and exports on their cycle: deleting the live copy while the export remains is not deletion.
• Never use Platform data beyond the purpose it was provided for. No sale of data, no sharing beyond the service providers your service genuinely requires, no marketing use of buyer data the buyer did not consent to. API Policies states the usage rules.
• Card data never touches your systems. See Payments: your integration receives payment identifiers and states only. Accepting, logging, or transmitting raw card data is a critical violation and a liability, full stop.

Intellectual property and content duties

If your integration supplies product content, it must be yours to supply: genuine goods under their true brands (Brand and Manufacturer), your own or licensed imagery and copy, accurate descriptions. Counterfeit goods and copied content are removed, repeat supply ends access, and rights-holder notices are handled under the Platform's copyright process: legal notices, including infringement notices, go to legal@aapawz.com.

Breach notice

When your integration is breached: keys exposed, Platform data accessed by unauthorized parties, buyer data lost: the duties are speed and candor, under the Breach Notification Requirements

1. Contain first: revoke exposed keys, disable the affected integration paths, preserve logs for investigation.
2. Notify the Company promptly at legal@aapawz.com, with what happened, when it was discovered, what data and accounts are affected, and what you have done. The timelines and required content are in Breach Notification Requirements; do not wait for a complete investigation to make the first notice.
3. Cooperate and remediate: follow the Company's directions on the affected integration, notify affected parties as required, and document the root cause and the fix.

Prompt, honest disclosure is treated as mitigation; concealment converts an incident into a termination case (Governance). Security vulnerabilities you discover in the Platform itself are reported under the Vulnerability Disclosure Policy: never probed further, never exploited, never disclosed publicly first.

Before you ship: the checklist

• Keys and signing secrets in a secrets manager; none in source control, logs, or client code.
• TLS verification on, for API calls and your webhook endpoint alike.
• Webhook signatures verified on every delivery, before any processing.
• Rotation rehearsed; revocation tested; leavers' access reviewed.
• Data inventory written down: what Platform data you hold, where, why, and its deletion schedule.
• Breach contacts and the notice procedure in your runbook, with legal@aapawz.com in it.

Threat-model your integration before it ships: what happens if the key leaks, if the webhook endpoint is discovered, if a connected account's grant is abused, if your database is breached. The answers should be uneventful: rotated keys, verified signatures, revoked grants, minimal data, and a notice sent early. Security work gets no credit for working; it gets noticed for failing. Build for the day you are glad nobody noticed.

Security questions: support@aapawz.com. Breach notices and legal notices: legal@aapawz.com.