Developer Data, Privacy, and Team Access

Separate businesses stay separate

Developer workspaces scope products, customers, orders, credentials, and operational information to the relevant business. Team membership in one workspace does not confer access to another developer's customer records.

Roles and product assignments

Team invitations and assigned roles determine permitted actions. Product scope limits which products a staff member can manage. Finance, credentials, customer access, and publication actions need their applicable permissions rather than one shared owner login.

Sessions and accountability

Revoking a staff session or changing access should affect subsequent authenticated requests. Activity records support review of sensitive changes. A visible menu or hidden button is not the authorization boundary; the service must enforce the permission.

Customer data and marketing

Access to customer records is for the developer's products and permitted business purposes, not unrestricted reuse of a platform audience. Imported contacts still require a lawful basis for marketing and must respect suppressions and unsubscribe requests.

Privacy requests and retained records

Send access, correction, export, deletion, or account-closure requests to support@soundsyncsolutions.biz. We aim to acknowledge privacy requests within five business days and respond without undue delay, ordinarily within one calendar month of receipt. We explain any legally permitted extension, identity checks, retained records, and next steps within the applicable deadline; verification is not a blanket reason to restart the clock. Closing an account, unsubscribing from marketing, and deleting personal information are different requests. No instant, all-record deletion is promised.

SoundSync retains information for the purpose it serves: operating accounts and purchased access, handling support, honoring marketing preferences, securing the service, and meeting applicable tax, accounting, dispute, and legal obligations. Unnecessary information should be deleted or anonymized. There is not one blanket retention period for all information.

Financial participation does not expose customer records

Affiliate and collaborator agreements do not grant developer workspace access, reseller privileges, or unrestricted customer information. Recipients receive the agreement, referral activity, allocation, and payout information needed for their own participation. Team access is assigned separately. Neither a click count nor an agreement gives access to a public customer list.

Customer identity and support permissions

A developer cannot use customer contact editing to replace a linked account email or password. Customers control those credentials through account recovery and verified settings. Workspace-wide contact edits, removal, imports and verification resends require all-products access; assigned-product permissions alone are insufficient.

Supported name and phone corrections can update a shared customer profile used by relevant developer relationships. Contact removal removes the requesting developer relationship, not another developer relationship, the global login or required purchase records.

Product access and private business information

The product overview separates product access from sales results, private reviews, delivery-file details and integration configuration. Each section follows the relevant team permission. Restricted information is unavailable to that role, not evidence that no sales, reviews or files exist.

Sensitive dashboard sections stay permissioned

Analytics access does not grant private customer snapshots, billing charges, settlement balances or reseller administration. Those dashboard sections follow the matching record permission. Goal editing requires owner or administrator settings access; read-only analysts retain their permitted analytics.

Connection diagnostics respect record permissions

Permission to inspect a product integration does not grant access to its customer identities or serial keys. Product connection diagnostics require credentials.view and an assigned product. Customer identity and device-linked fields additionally require customers.view; serial fields require serials.view. Restricted fields are returned as null.

Failure explanations and arbitrary nested metadata can repeat customer or serial details, so they are returned only when both record permissions are present; otherwise the explanation is null and metadata is empty. Customer-specific connection history also requires customers.view and all-products scope. Event kind, status, version, environment and timestamps remain available to permitted diagnostic users.

Separate billing reports from payment-method management

Billing reports, invoices, statements and their CSV downloads remain available with billing.view and all-products workspace scope. Opening the developer Stripe billing portal additionally requires billing.manage because that portal can change payment methods and billing contact details.

POST /api/developer/billing/portal-session returns 403 developer_team_permission_denied when billing.manage is missing. Existing role definitions stay unchanged: a read-only billing viewer cannot use the editable portal. This is separate from owner-only Stripe Connect payout onboarding, the customer subscription portal and any transfer execution.