Security is part of the operating model.
YEEDOOR connects merchant-authorized commerce, fulfillment, marketing and analytics platforms. We design those connections around least privilege, official authorization flows, encrypted credential storage, tenant boundaries, auditable actions, data minimization and platform-specific compliance controls.
OAuth, seller authorization, app credentials or other official platform mechanisms. We do not ask merchants to share marketplace passwords.
Application secrets and merchant authorization tokens are protected at rest and are not exposed in customer-facing pages or source repositories.
High-impact actions are approval-gated or constrained by merchant-configured automation rules, platform permissions and audit history.
Trust Center status
This page describes YEEDOOR's current security design and the platform requirements we build against. Platform terms may change and the current platform documentation always controls.
1. Core security controls
Transport security
Public YEEDOOR services use HTTPS/TLS. Production web endpoints are configured to support modern TLS and security headers appropriate to each service. Authentication callbacks and API traffic are sent over encrypted connections.
Secrets, tokens and credential storage
- Platform client secrets, refresh tokens, access tokens and merchant authorization credentials are treated as secrets.
- Production secrets are supplied through controlled environment or secret-management paths rather than embedded in public web pages or source code.
- Merchant OAuth credentials are encrypted at rest. YEEDOOR uses application-specific encryption and protected server-side credential stores for supported connectors.
- Customer-facing interfaces use secure references and connection status rather than displaying raw secrets.
- Secrets are rotated or revoked when compromise is suspected, access ends, or a platform requires rotation.
Least privilege and authorization
YEEDOOR requests only the platform scopes, roles and permissions needed for enabled merchant features. Scope requests are mapped to specific functions such as product management, inventory, order processing, fulfillment, tracking, customer service, finance or merchant-approved marketing operations. Sensitive or restricted data is requested separately when the platform requires enhanced review.
Tenant and access boundaries
Merchant data and connected credentials are scoped to the authorized merchant, store, seller account or workspace. Administrative access is limited to authorized operational roles. Privileged access is separated from merchant-facing access and is subject to access-control procedures.
Webhook and event integrity
Where a platform provides signed webhooks or event notifications, YEEDOOR validates the platform's authenticity mechanism before acting on the event. Depending on the platform this can include HMAC/signature validation, public-key verification, verification tokens, timestamp checks and replay protection.
AI action governance
YEEDOOR AI Operating Team can analyze connected data, recommend actions and perform supported actions within granted permissions. High-impact actions remain approval-gated unless a merchant has explicitly enabled an allowed automation and the platform permits it. Supported writes are followed by read-back verification or execution status checks where practical, with audit history for operational accountability.
Customer contact data and transactional email
Buyer or customer contact data is accessed only when the connected platform explicitly permits it and the merchant workflow requires it. Order-related contact data, including buyer email where separately approved, is used for legitimate transaction and service purposes such as fulfillment exceptions, out-of-stock substitution confirmation, shipping issues, returns, refunds and buyer-requested support. It is not used for unsolicited marketing, credential collection or redirecting buyers to complete an off-platform transaction in violation of marketplace rules.
Data minimization, retention and deletion
YEEDOOR aims to retain only the data reasonably required to provide enabled features, maintain security and auditability, satisfy legal obligations, resolve disputes and meet platform rules. Revocation, uninstall, account deletion and platform privacy events are handled according to the applicable platform and YEEDOOR retention requirements. When data is no longer required, it is deleted or de-identified subject to reasonable backup and security-log retention cycles.
Logging and incident response
Operational logs are designed to avoid raw credentials and unnecessary customer personal data. Security incidents are handled through containment, credential or session revocation, secret rotation, investigation, remediation and required merchant, platform or authority notification where applicable.
2. Platform-specific requirements we track
The following controls are part of YEEDOOR's connector review checklist. They summarize the security and privacy obligations that materially affect our architecture. They do not replace each platform's current developer agreement, privacy terms or security documentation.
Shopify
OAuthMandatory compliance webhooksProtected customer data- Use Shopify's official authorization flow and request only required app scopes.
- Implement mandatory privacy/compliance webhooks and verify Shopify HMAC signatures; invalid signatures must not be accepted.
- Protected customer data is minimized and handled only for approved app functionality and approved access levels.
- Store credentials are removed or invalidated when an installation ends, and applicable customer/shop deletion requests are processed.
- The Shopify-specific security page remains available at Yeedoor AI Store Manager Security.
Amazon Selling Partner API (SP-API)
LWA OAuthRolesRestricted data / PII- Follow Amazon's Acceptable Use Policy, Data Protection Policy and Solution Provider requirements for SP-API access.
- Request only required SP-API roles. Restricted roles and PII access require enhanced security review and documented business need.
- Protect LWA client secrets, refresh tokens and access tokens. Use restricted-data controls required by the specific API version and operation; legacy restricted operations can require Restricted Data Tokens, while newer APIs can use documented role-based PII access.
- Encrypt sensitive data, restrict staff access, maintain vulnerability and incident-response controls, and answer Amazon developer-profile security questions consistently with implemented controls.
eBay
OAuthData Protection AddendumAccount deletion notifications- Keep eBay Client Secrets and user tokens confidential and use secure OAuth authorization.
- Maintain a public privacy policy consistent with eBay's API License Agreement and process personal information only for permitted purposes.
- Delete personal information when no longer necessary or when eBay/user deletion obligations apply.
- Subscribe to Marketplace Account Deletion/Closure notifications or use eBay's permitted opt-out process if no eBay user data is persisted; this is a production-access requirement for third-party developers.
- Do not use eBay personal information for unsolicited communications. Do not place real confidential or personal data into eBay Sandbox test environments.
Walmart Marketplace
OAuth 2.0Minimum scopesDynamic Sandbox- Use Walmart OAuth 2.0 and protect Client ID/Client Secret and seller access/refresh tokens.
- Approved Solution Providers request only the minimum API scopes necessary; scopes are shown to sellers during consent.
- Use sandbox environments for safe integration tests before production writes where available.
- Fulfillment, WFS, Shipping and other specialized capabilities are enabled only when the merchant and application have the relevant permissions.
Etsy
OAuth + PKCECommercial Accessbuyer_email approval- Private member data uses OAuth; YEEDOOR does not sidestep Etsy Open API by screen-scraping or browser automation for production data access.
- Follow Etsy API Terms, caching requirements and trademark rules. Commercial applications must clearly state that Etsy is a trademark of Etsy, Inc. and that the application is not endorsed or certified by Etsy.
- Commercial Access applications using transaction access must separately request buyer_email field access when buyer email is required.
- Buyer contact data is restricted to legitimate order, fulfillment, return/refund and support communication; not unsolicited marketing or off-platform diversion.
TikTok Shop
Seller authorizationApp secretsWebhook verification- Protect application secrets, seller tokens and merchant authorization state.
- Request only scopes required for enabled seller operations.
- Verify webhook signatures and timestamps before processing events; reject stale or invalid signed payloads to reduce spoofing and replay risk.
- Process buyer/seller personal information only within the permissions and current TikTok Shop partner terms applicable to the app.
Temu Partner Platform
Seller authorizationPermission selectionCallback flow- Seller authorization determines the permissions an ISV can use. YEEDOOR does not treat app registration as permission to access seller data.
- Where callback authorization is available, validate authorization state and the configured redirect URI, exchange codes server-side and protect resulting access tokens.
- Manual tokens, when a Temu seller flow requires them, are treated as credentials and stored only in protected server-side storage.
- Regional seller endpoints and authorization modes are kept separate so tokens and data are not mixed across regions.
Lazada Open Platform
App Key / App SecretSigned requestsSensitive Data Privilege- Keep the Lazada App Secret strictly confidential and never expose it in client-side code.
- Sign API requests according to Lazada's current signature algorithm and reject invalid integration traffic.
- Buyer personal information is treated as sensitive data; Lazada identifies Sensitive Data Privilege as requiring security audit approval before access.
- Seller tokens and region-specific marketplace data are isolated to the authorized seller and market.
Shopee Open Platform
Partner credentialsShop authorizationSigned API protocol- Partner keys/secrets and shop authorization tokens are handled as credentials and kept server-side.
- Each connected shop is isolated by merchant/shop identity; tokens are not reused across unrelated sellers.
- YEEDOOR validates signed requests, callbacks or webhook/event messages where required by the current Shopee Open Platform protocol.
- Permissions are limited to the API groups needed for product, inventory, order, fulfillment and merchant-enabled operations.
AliExpress Open Platform
App credentialsSeller authorizationRequest signing- App secrets and seller access tokens are stored only in protected server-side credential stores.
- Seller authorization is required before seller data or seller actions are performed.
- Requests are signed or authenticated according to the current AliExpress Open Platform protocol and only the required API permissions are requested.
- Order/customer data is limited to permitted operational purposes and deleted or de-identified when no longer required.
DHgate Open Platform
Developer credentialsSeller authorizationToken isolation- Application credentials and seller authorization tokens are protected from client-side exposure and unauthorized staff access.
- Seller-scoped data remains isolated by merchant and authorized account.
- YEEDOOR follows the current DHgate Open Platform authentication/signature requirements and requests only the API permissions needed by enabled merchant features.
- Customer/order personal information is handled only for permitted transaction and service workflows.
BigCommerce
OAuth app installStore-scoped tokensLeast scopes- Use BigCommerce's official app authorization flow and HTTPS callbacks; do not collect a merchant's BigCommerce password.
- Store access tokens are isolated by store and protected at rest.
- Request only the scopes needed for enabled APIs such as catalog, orders, customers, shipping or store settings.
- Uninstall/revocation events trigger credential invalidation and applicable data-retention/deletion handling.
Mercado Libre / Mercado Livre
OAuthRedirect controlsNotifications- Application secrets and OAuth tokens remain server-side and are scoped to the authorized seller/user.
- Redirect URIs and OAuth state are validated before token exchange.
- Platform notifications are authenticated/validated according to the current developer protocol before they drive order, listing or fulfillment actions.
- Personal or order data is processed only for the merchant-authorized use case and removed when authorization or retention requirements end.
3. Connected marketing, analytics and search services
Google-connected services
Google OAuth data is limited to the scopes and assets the user grants. YEEDOOR follows the Google API Services User Data Policy, including Limited Use requirements. Google user data is not sold and is not used to train generalized AI or machine-learning models. Users can revoke authorization, and YEEDOOR processes deletion requests for applicable stored Google-derived data.
Meta and other advertising platforms
Advertising credentials, page/account IDs and campaign data are handled through official platform authorization where available. Write actions remain limited to granted assets and merchant-approved or merchant-configured workflows. Platform advertising policies continue to apply independently of YEEDOOR.
4. Fulfillment and cross-channel operations
YEEDOOR is designed to support cross-channel fulfillment workflows such as a marketplace order being routed to Amazon MCF, a 3PL or another authorized fulfillment provider, followed by carrier and tracking writeback to the source marketplace. Security controls for this workflow include seller authorization on both sides, minimum order data, protected delivery information, provider-specific credentials, audit history and strict separation between operational communication and marketing use.
5. Vulnerability and security reporting
If you believe you have found a security issue affecting YEEDOOR, contact aiken@yeedoor.com. Please do not include passwords, access tokens, full customer records or other unnecessary personal data in the initial report. Include a concise description, affected URL or component, reproduction context and a safe way to contact you.
6. Related public policies
7. Changes to this Trust Center
Commerce platforms update APIs, security standards, privacy requirements and review processes over time. YEEDOOR updates this page as our architecture or material platform requirements change. Where this page conflicts with a platform's current binding developer terms, the platform's current terms govern that integration.