Published: September 15, 2026
Last updated: September 15, 2026
Effective: September 15, 2026
Personal information handler: Yoghourt Technology(BeiJing) Company Limited ("we", "us", or "Pakta")
Privacy contact email: support@pakta.site
Official website: https://pakta.site
1. Scope and our role
This Policy explains how we process personal information when providing the Pakta website, developer console, hosted APIs, and SDKs and CLI tools connected to our hosted services, and how you can exercise your rights. Personal information includes information that identifies an individual on its own or in combination with other information. Random identifiers and de-identified data are not automatically anonymous.
For website visits, developer accounts, orders, and platform security, we act as the personal information handler for the respective purposes. For end-user update information entrusted to us by application developers, we act as an entrusted service provider under our agreement. Developers determine how to integrate and enable the service and configure update policies in their applications, and provide the applicable privacy notices to end users.
If you use an application that integrates Pakta, also read that application's privacy policy. You may contact its developer or ask us to help identify the responsible party. For independently deployed services, the actual operator explains its own processing. Publishing open-source code does not mean we can access all data in applications using that code.
2. Information we process and why
We collect information necessary for each specific feature. If you do not use an optional feature, we do not require additional information for it. Public documentation can be read without an account. References below to contractual necessity apply only where an individual is a party to the contract and the processing is objectively necessary. A contract with an organization does not mean all its employees or end users have authorized processing.
2.1 Website and developer services
| Activity | Information and sources | Purposes and processing | Basis and effect of refusal |
|---|---|---|---|
| Email registration, login, and account recovery | Email, password, and verification code you provide; generated user ID, verification status, session times, and credential digests | Send verification emails, authenticate, establish and revoke sessions, and prevent impersonation; passwords are stored as hashes | Processing necessary for an individual's contract or lawfully obtained consent; without required information, the account cannot be created, but public content remains accessible |
| Profile | Display name, avatar URL, and information you choose to submit | Display account identity and support collaboration and account management | Voluntary submission; optional fields can be left blank |
| GitHub login or linking | GitHub user ID, username, verified email, and avatar URL you authorize; temporary authorization credentials | Verify, create, or link an account | Necessary permissions obtained through the authorization flow; email login is an alternative |
| Access tokens and authorization | Token name, purpose, digest, permissions, application scope, expiration and usage times; MCP client name | Authenticate API, CLI, and MCP requests, restrict access, and support revocation | Necessary for interfaces you enable; features that do not require a token remain available without creating one |
| Membership orders, payment, and reconciliation | User ID, plan, order number, amount, credits and entitlement records, payment channel, result, transaction identifiers; ordering IP; OpenID you provide for certain WeChat payment methods | Create payment orders, verify payment, grant entitlements, handle refunds and financial records; necessary fields are sent to the selected payment provider | Order performance and related legal obligations; required information is necessary to complete the transaction |
| Business operations and security audit | Acting account, time, IP, User-Agent, request method and path, result code, and business request summaries subject to sensitive-field handling and length limits | Investigate anomalies, trace releases, prevent abuse, and meet applicable security obligations | A lawful basis for security protection, including applicable legal obligations; not extended to unrelated profiling |
| Email support, complaints, and rights requests | Email, issue description, order number, diagnostic materials, and information necessary to verify your request | Answer questions, resolve disputes, verify requests, and fulfill rights-response obligations | Handling your request and applicable legal obligations; avoid unrelated identity documents, passwords, or end-user data |
| Network connections and basic protection | IP, access time, request address, browser or client information, and security detection results generated during connections | Establish connections, deliver content, prevent attacks, and control traffic; processed by servers and the infrastructure actually used | Necessary connectivity and security; the relevant network request cannot complete without necessary information |
| Website analytics | Page address, referral source, visit time, browser and device environment, cookies or similar identifiers, and page interactions; Clarity also uses page structure and interaction data for session replay | Analyze website use and identify navigation and page issues through third-party scripts | Valid prior consent where required; visiting or accepting this Policy does not replace consent; requests can be made by email |
Payment providers may independently collect card, payment account, or identity verification information on their payment pages. Do not send payment passwords or complete card credentials to Pakta. If an actual payment notification or support process requires us to handle account fields that constitute sensitive personal information, we will explain their specific categories, necessity, and impact before processing and meet applicable separate-consent and other requirements.
2.2 SDK end-user update information
After a developer enables the relevant update features and establishes the applicable legal basis, the SDK processes the following information when the relevant events occur. Automatic checking, activation, and launch behavior depend on the integrated version and developer settings and are not limited to manual user actions.
| Activity | Information | Purpose |
|---|---|---|
| Update checks, including enabled checks at launch | Protocol fields such as application identifier, channel, native package version, build identifier, current update package or code digest, update status, SDK/RN versions, and random client identifier | Match compatible updates, control staged rollouts, and avoid sending incompatible updates |
| Artifact downloads | Application and artifact identifiers, download requests, and connection information such as IP | Deliver full or differential packages through distribution services and object storage/CDNs |
| Download success or failure, patch failure, rollback, and successful launch confirmation | Event type, application, channel, version, build identifier, package digest, SDK/RN versions, system information, random client identifier, event time, and failure details | Measure update outcomes, diagnose faults, and identify affected versions or clients |
| Update decision diagnostics | Application, channel, version, build and code digests, SDK/RN versions, update status, decision, reason, and time | Explain why an update was or was not offered; this dedicated record does not store device identifiers, IP, or the raw request body, which does not mean other network logs never process IP |
| Local device state | Random client identifier, installed and pending version state, downloaded artifacts, and recovery state | Maintain rollout grouping and version state, install updates, activate on restart, or recover from failure |
The client identifier is generally generated by the SDK and persisted locally in the application for staged rollouts and diagnostics. This does not make it incapable of identifying an individual. We apply safeguards according to its linkage risks. Developers must not replace it with a national ID number, phone number, email, or other direct identifying information.
These OTA features do not require access to contacts, text messages, microphone or camera content, or precise location. Permissions requested by the application or other SDKs must be explained by the relevant provider. Failure details may contain runtime information; developers should prevent credentials or unrelated personal data from being included in errors. Truncating a string does not replace removing sensitive information.
Receiving update information does not give us access to all end-user business data within the application. Additional information embedded in customer-uploaded artifacts does not authorize its additional collection.
2.3 Specific uses of payment information
When you purchase, renew, or upgrade Pakta membership, we use a payment gateway to connect to your selected Stripe, Alipay, or WeChat Pay channel and process information necessary for that transaction:
| Purpose | Information and processing |
|---|---|
| Create and associate an order | Associate your Pakta account with the plan, amount, currency, purchase type, and order number; send the gateway a product description, order expiration, account association identifier, and necessary transaction parameters to generate a payment link, QR code, or payment launch information |
| Initiate the selected payment method | Send the ordering IP to the gateway as network information; WeChat payment within an official account additionally uses OpenID to initiate the corresponding user's payment. Other channels do not require OpenID on that basis. Fields forwarded downstream are limited by the actual integration |
| Confirm payment and transaction security | Receive order identifiers, payment status, amount, channel, and success time from the gateway; verify signatures, merchant, currency, and amount to prevent incorrect notifications, order mismatches, or duplicate processing |
| Activate, renew, or upgrade membership | Use confirmed payment and the order's plan, credit, and previous entitlement snapshot to update membership tier, validity, and benefits and retain necessary change records |
| Check orders and resolve exceptions | Use order numbers, transaction identifiers, status, and time to check payment, display paid orders, and resolve missing entitlements, late payments, and order conflicts; use relevant records to assess billing disputes or refund requests |
| Retain necessary transaction evidence | Retain necessary transaction records under Section 5 and applicable statutory periods for reconciliation, disputes, and legal retention obligations |
These payment integrations support membership transactions and related services. Choosing a payment method does not authorize advertising profiles or unrelated marketing using transaction data. We do not create a transaction with a payment gateway merely because you browse public content without initiating a paid order. Zero-cost entitlement adjustments do not initiate third-party collection of funds.
Card information, payment account verification, and payment passwords are handled as needed by the selected payment provider in its payment environment. We currently confirm payment using transaction results such as order, amount, channel, status, and time and do not require you to submit full card numbers, security codes, or payment passwords to Pakta. Payment providers may independently process necessary information for payment, authentication, transaction security, and legal obligations under their own policies. This does not mean Pakta collects or obtains all information held by those providers.
You may choose another available payment channel or choose not to purchase. Refusing information required for a particular method may prevent payment through that method but does not affect access to public content. Accepting a refund request does not mean the platform provides an automated refund API; requests are handled under the Terms of Service and the actual processing outcome.
3. Cookies, local storage, and website analytics
Login state. The console stores login tokens, expiration times, and account summaries in browser local storage to maintain sessions. Logging out clears the corresponding local session; server-side revocation follows the authentication mechanism. Clearing site data may also log you out.
Language preferences. Your language choice is stored locally and in a
pakta-localecookie for subsequent visits. That cookie currently has a one-year lifetime, which may be refreshed when you select a language again. Local storage generally remains until overwritten or deleted by the application or cleared by you.Analytics. The website integrates Google Analytics 4 for visit statistics and Microsoft Clarity for heatmaps and session replay analysis. Information may be associated with browser identifiers. Contact support@pakta.site about processing, restrictions, or withdrawal of consent. Where consent is legally required, we must obtain valid consent before processing. Merely browsing or accepting this Policy does not provide that consent.
Information categories and retention arrangements for analytics appear in Sections 4 and 5. Browser settings can manage cookies or clear site data, but this may affect login and preferences and does not guarantee that all requests not relying on cookies are blocked.
We do not intentionally send passwords, access tokens, payment information, or URL parameters containing personal information to analytics providers and must limit replay scope and protect sensitive page content.
4. Providers, sharing, and other disclosures
4.1 Third-party processing list
The following table identifies confirmed service brands and their processing purposes, as relevant to the features you actually use.
| Service | Recipient and contact | Information, purpose, and method | Regions and retention |
|---|---|---|---|
| GitHub login | GitHub; privacy statement | You initiate authorization; GitHub processes that request and we obtain the identity information in Section 2. External avatars may send browser network information to the image host | Identity information we hold follows Section 5; GitHub's own processing follows its statement |
| Email delivery | Feishu Mail; service and contact | Deliver account verification, password reset, and necessary service emails using recipient addresses, message content, and delivery information; verification emails do not authorize unrelated marketing | Records under our control follow Section 5; provider email and security records follow its applicable rules |
| Stripe payments | Stripe; privacy policy and rights requests | If selected, create a hosted checkout order through the gateway using order, amount, product, and channel-required information; Stripe independently collects payment details on its checkout page and returns payment results | Our transaction records follow Section 5; Stripe retains its own records under payment and legal obligations. The actual service entity and principal processing regions are disclosed separately according to the merchant account |
| Alipay | Alipay; terms and privacy policy | If selected, send order, amount, product, and necessary transaction information through the gateway to complete payment and verify the result; the payment provider handles account verification | Our records follow Section 5; provider records follow its payment rules and legal duties. The recipient entity and processing regions are disclosed separately according to the merchant integration |
| WeChat Pay | WeChat Pay (Tenpay Payment Technology Co., Ltd.); privacy policy and contact | If selected, pass order, amount, product, and necessary transaction information through the gateway. Payment within an official account also uses OpenID to initiate that user's payment; other methods do not additionally collect OpenID on this basis | Our records follow Section 5; provider records follow its payment rules and legal duties. Processing regions are disclosed separately according to the actual integration |
| Alibaba Cloud | Alibaba Cloud; privacy policy and contact | Cloud infrastructure for services actually deployed on its facilities; processes relevant business data, artifacts, and necessary network information according to the hosted function. Listing a provider does not mean it receives all data | Global deployment; recipient entities and principal processing regions are identified in relevant specific notices. Retention under our control follows Section 5 |
| Tencent Cloud | Tencent Cloud; privacy statement and contact | Cloud infrastructure for services actually deployed on its facilities; processes relevant business data, artifacts, and necessary network information according to the hosted function. Listing a provider does not mean it receives all data | Global deployment; recipient entities and principal processing regions are identified in relevant specific notices. Retention under our control follows Section 5 |
| Cloudflare | Cloudflare; privacy policy and contact | Infrastructure for services actually connected to it; depending on enabled features, processes request addresses, IP, access time, client environment, and relevant content transmitted or stored through its facilities | Global deployment; recipient entities and principal processing regions are identified in relevant specific notices. Retention under our control follows Section 5 |
| Google Analytics 4 | Google; privacy policy | Analytics scripts process page visits, sources, environment, and browser identifiers to generate website analytics; prior consent is required where applicable | Configured event and user-level retention is addressed in Section 5; Google's own processing follows its policy |
| Microsoft Clarity | Microsoft; privacy statement | Scripts process browser identifiers, environment, page interactions, and replay data for heatmaps and session analysis; prior consent is required where applicable. Independent provider purposes must be specifically disclosed under applicable terms | Replay and heatmap retention appears in Section 5; Microsoft's own processing follows its statement |
Third-party policies supplement information about their processing and do not replace our specific disclosures about recipients, purposes, and scope. Where providers use data independently, their role and legal basis must be identified separately; they cannot all be treated as acting solely on our instructions.
4.2 Processing rules
For entrusted processing, we contractually limit purposes, information scope, and security responsibilities and provide necessary supervision. When providing information to independent personal information handlers, we meet applicable notice and separate-consent requirements. Where law provides a basis that does not require consent, processing is limited to the scope of that basis.
If you connect an external MCP or CI tool, it may receive data within the token's authorized scope. Configuring MCP does not automatically send all business data to a model provider. Actual recipients depend on the client and service you connect. Review their information handling rules before authorization.
If data is transferred due to a merger, division, or similar event, we will identify the recipient and contact details and require continued protection. Changes to the original purpose or method require renewed authorization as applicable law requires. Except as law requires or valid authorization permits, we do not publicly disclose personal information. We do not sell personal information.
5. Storage locations, retention, and deletion
5.1 Global deployment and cross-border processing
Pakta uses globally distributed infrastructure. Depending on the features you use, service configuration, and operational needs, relevant data may be stored, cached, transmitted, and processed in our or our providers' facilities in different countries or regions for service delivery, content distribution, backup and recovery, and security.
Arrangements may differ by data category. Providers, purposes, information scope, and principal processing regions are described in Section 4 and relevant specific notices. Unless expressly agreed otherwise or required by applicable law, we do not commit to restricting data to a single country or region.
Before a cross-border provision of personal information, we will provide legally required information about the overseas recipient's name, contact details, processing purposes and methods, information categories, and rights channels, obtain any required separate consent, and fulfill applicable cross-border procedures and security obligations. Use the contact information in this Policy for questions or rights requests.
We update relevant information as infrastructure arrangements change. Where a change requires renewed notice or consent, the corresponding process occurs before the changed processing begins.
5.2 Retention schedule
We retain information for the shortest time needed for its specific purpose. Fixed cleanup periods and purpose-based retention are distinguished below. Where a single period cannot be established, retention is determined by identifiable events such as whether service performance continues, a credential remains valid, an issue is resolved, or a statutory retention obligation expires. An active account does not justify keeping all historical data. Legal obligations apply only to necessary records, not all account information.
| Category | Period or method of determination | Treatment when no longer needed |
|---|---|---|
| Developer accounts, profiles, and linked identities | While the account is active and the service requires them; after closure, only necessary records with a specific statutory basis remain | Delete or anonymize; restrict processing of legally retained portions |
| Password authentication, sessions, and access token records | While authentication remains valid and for necessary replay prevention; after invalidation, retain relevant records only for specific security investigations or required legal retention. Password hashes are retained with the account | Invalid credentials cannot authenticate; physical records are cleaned separately. Invalidation is not deletion |
| SDK runtime events and associated random identifiers | Standard cleanup period: seven days from the event | Scheduled removal of expired records; scheduling may cause a delay relative to the precise event time |
| Update decision diagnostics | Current implementation: seven days from the record time | Periodic deletion |
| Administrative operation audit | One hundred eighty days from the operation; necessary records also serving as statutory cybersecurity logs follow the next row | Remove after expiration; manage business audit and statutory security retention separately |
| Cybersecurity logs | Records subject to mainland China's statutory network operation and security event retention duties are kept for six calendar months from creation; longer periods apply where law or a competent authority lawfully requires | Remove when the statutory period ends and no further basis exists; one hundred eighty days is not treated as equivalent to six calendar months |
| Ordinary operations, CDN, gateway, and email delivery logs | As necessary for request delivery, retries, and specific troubleshooting; ordinary troubleshooting is not a basis for continued retention after its purpose ends. Necessary statutory security or transaction records follow their respective rules | Promptly remove unnecessary records; provider records processed independently follow the provider's specific disclosures |
| Order and payment business records | During entitlement performance and necessary reconciliation; afterward, only necessary records for applicable transaction or financial retention duties or specific unresolved disputes, until the obligation, dispute, or lawful preservation ends | Potential disputes do not justify indefinite retention of all information; promptly remove unnecessary account links and request details |
| Accounting vouchers and books | Vouchers and books qualifying as statutory accounting archives are retained for at least thirty years from the first day after the relevant accounting year ends, under applicable rules. Other accounting archives follow their statutory categories | Follow statutory appraisal and destruction procedures; this period does not extend to all raw order requests or other business data |
| Support and rights requests | From receipt through resolution; afterward, only necessary materials for outstanding review, disputes, or evidence of legal compliance until the matter or statutory period ends | Promptly remove unrelated attachments and unnecessary communications; do not routinely archive entire submissions long term |
| Google Analytics 4 | Event and user-level information is retained for the shortest period needed for the relevant analysis and is subject to the service's event retention window. Standard aggregate reports and independent provider purposes do not share the same setting | Remove identifiable analytics data no longer needed; genuinely anonymous statistics that cannot be reversed to identify individuals may remain in use |
| Microsoft Clarity | Under the provider's current published rules: ordinary replays for thirty days; sampled, tagged, or favorited replays, heatmaps, and click data for up to nine months | Local deletion does not replace provider deletion; do not export identifiable replay copies for additional long-term storage. Other independent provider purposes require separate disclosure |
| Information potentially embedded in customer artifacts | During service storage and the contractual return window; active deletion requests are handled under law and contract | Delete active stored copies and unreferenced objects; caches and backups exit through their defined cycles |
| Backup copies | Determined by recovery-point needs and backup rotation. When source information is due for deletion, corresponding backup data stops being used for normal business and is removed at an executable cleanup or overwrite step. No additional copies are made to extend business retention | If selective deletion is temporarily technically unavailable, isolate storage and limit use to necessary security protection; reapply effective deletion requests when restoring |
| Cache and message queue copies | Only during request reuse, task execution, and necessary retries; remove when a task completes or ends or a cache loses its business purpose. Required statutory retention is handled through the relevant records | Promptly invalidate or remove when no longer needed or upon a valid deletion requirement; artifact caches must support takedown and cannot continue unlawful distribution |
When a period expires, a purpose is fulfilled, or you lawfully request deletion, we delete or anonymize information according to the relevant rules. Where law requires retention or deletion is temporarily technically difficult, we stop processing other than storage and necessary security measures and explain the circumstances. De-identification is not anonymization and does not justify indefinite retention of linkable data.
6. How we protect information
We use authentication, access restrictions, credential protection, necessary logs, and cleanup mechanisms according to data risk. The current system hashes account passwords, provides scoped and revocable access tokens, and masks specified sensitive fields in audited requests. These measures do not mean all personal information can be automatically identified and removed from every text field.
We maintain transport protection, access approval, provider management, and incident response measures appropriate to the actual deployment. Access to non-public customer information is limited to personnel who need it for their duties. We do not promise unverified certifications, universal encryption, or absolute security.
If information is at risk of disclosure, alteration, or loss, we will promptly take remedial measures, notify affected individuals or the entrusting party, and report to authorities as applicable requirements prescribe. Notices explain the impact, measures taken, steps you can take, and contact details. Where statutory conditions permit notification other than individual notice, we follow those rules.
7. Your rights and how to exercise them
Email support@pakta.site to request access, copies, correction, supplementation, deletion, restriction, withdrawal of consent, account closure, or eligible information transfers, or to ask for an explanation of this Policy. We verify only the information necessary for the request and do not impose unreasonable conditions. Withdrawal does not affect processing based on valid consent before withdrawal. For legally retained records, we restrict purposes and explain the basis.
For end-user data whose processing is determined by an application developer, we assist the developer with verification and handling. We may request minimal information such as the application name and issue time, and do not collect additional permanent device identity information simply to locate a request.
Within fifteen working days of receipt, we respond with the outcome or progress. If a complex request needs more time, we explain why and provide an expected completion date. Shorter statutory deadlines take priority. Reasonable requests are generally free. If an exception permits a fee, we explain its basis and amount in advance. If we cannot fulfill a request, we explain the reason and available appeal channels.
You may also complain to the competent personal information protection authority or seek judicial remedies under applicable law.
8. Children's and minors' information
Pakta's developer services primarily serve professional users with the necessary legal capacity and do not target children. This does not mean every integrated application is free of minor users.
If a developer's application involves children under fourteen, the developer must define the entrusted processing scope, establish applicable dedicated processing rules, obtain guardian consent as required, and implement necessary safeguards before integration and activation. This general Policy does not replace that process.
If you believe we process a minor's information without a lawful basis, contact our support email. We will investigate and stop processing, delete information, or take other necessary protective measures. Without a separate arrangement, the service should not receive children's identity, education, or health information unrelated to OTA purposes.
9. Policy updates and contact
We update this Policy and explain changes when new information categories are introduced or purposes, important recipients, or rights channels change. Material changes are communicated through prominent notices and reasonably accessible channels. Where renewed or separate consent is required, we obtain it before the relevant processing begins and do not infer acceptance from continued access.
Contact support@pakta.site with questions or to request the applicable policy text and information about its effective date.