> ## Documentation Index
> Fetch the complete documentation index at: https://developer.timekettle.co/llms.txt
> Use this file to discover all available pages before exploring further.
# Privacy Policy
> How Timekettle Developer collects, uses, shares, stores, and protects data for developer accounts, APIs, AI translation services, and SDK integrations.
**Last Updated: June 26, 2026**
This Privacy Policy explains how Timekettle Developer ("Timekettle", "we", "us", or "our") processes information when you use Timekettle Developer websites, documentation, dashboards, APIs, SDKs, cloud services, AI translation services, offline license services, model management services, diagnostics, observability features, and related support channels (collectively, the "Services").
This policy applies to developers, customers, administrators, team members, and other people who interact with Timekettle Developer directly. It also explains how the Services may process information about end users of applications, websites, devices, or other products that integrate Timekettle SDKs or APIs.
Timekettle SDKs usually operate as technical components inside a developer-controlled product. For end-user audio, text, identifiers, device authorization data, and diagnostic files processed through that product, the developer is typically responsible for giving notices, requesting permissions, obtaining required consents, honoring user rights, and configuring the SDK lawfully.
## 1. Definitions
* **Developer** means the person or organization that creates an account, uses the developer dashboard, calls our APIs, integrates an SDK, or otherwise configures the Services for an app, website, device, or product.
* **End user** means a person who uses a developer product that includes or connects to the Services.
* **Customer content** means audio, speech, text, translation content, TTS output, files, prompts, metadata, and other data submitted to, generated by, or processed through the Services.
* **SDK** means a Timekettle software development kit, sample, tool, library, or integration package made available for developer use.
## 2. The information we process
The information we process depends on the features you use, your integration choices, your platform, your region, and your contract with Timekettle.
### 2.1 Developer account and service administration data
We may process:
* Account profile data, such as name, business email, company name, job title, password or authentication metadata, and account status.
* Organization and team data, such as workspace name, tenant ID, roles, permissions, invited users, team membership, and administrator settings.
* Service configuration data, such as AppID, ClientID, application name, package name, Bundle ID, API environment, region, language configuration, product settings, and enabled features.
* Credential and security metadata, such as API key identifiers, token status, request signatures, timestamps, nonces, IP address, user agent, login events, audit events, and access logs.
* Billing and commercial data, such as plan, quota, invoice metadata, payment status, usage quantities, order forms, and support entitlement. Payment card details, where required, are processed by payment providers and are not intended to be stored directly by Timekettle Developer.
* Support data, such as contact details, ticket contents, diagnostic attachments, logs you submit, messages with our support team, and feedback.
### 2.2 SDK initialization, authentication, and authorization data
To initialize SDKs, authenticate requests, prevent abuse, issue tokens, and enforce license terms, the Services may process:
| Scenario | Data processed | Purpose |
| ----------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- |
| SDK initialization and developer authentication | AppID, ClientID, package name or Bundle ID, app version, tenant ID, timestamp, nonce, request signature, network environment, interface base URL | Verify the developer, select the service environment, sign requests, and prevent replay attacks |
| Device binding and authorization | Device model, manufacturer, platform type, operating system version, app version, Android package name combined with hashed Android ID, hashed iOS IDFV, device public key, device key fingerprint | Bind a device or installation, issue user tokens, validate offline licenses, and maintain authorization consistency |
| User or installation context | Developer-configured `externalUserId`, `installId`, `tenantId`, and service-returned `user_id`, `tenant_id`, `region_id`, `roles`, `scopes`, and `offline_auth_enabled` | Keep tenants isolated, bind an account or installation, cache tokens, enforce permissions, and enable offline authorization |
Do not send phone numbers, email addresses, government identifiers, real names, or other directly identifying values as `externalUserId`, `installId`, or similar SDK context unless your use case, notices, consents, and security controls specifically support that processing.
### 2.3 Online AI translation, speech, and room connection data
When online translation, speech recognition, machine translation, text-to-speech, real-time audio, or messaging features are enabled, the Services may process:
* PCM audio, recognized speech text, translated text, and TTS audio.
* Source language, target language, channel, sample rate, speaker settings, translation scenario, engine configuration, VAD configuration, and message channel configuration.
* Room number, channel number, RTC or RTM UID, token, trace ID, connection state, and callback metadata.
* Timing, quality, and service metrics needed to route requests, provide callbacks, diagnose failures, and maintain service reliability.
Online mode may route relevant audio, text, translation, connection, and messaging data through Timekettle services and real-time communication services used by the integration.
### 2.4 Offline translation, license, and model data
When offline translation is enabled, SDK inference for recognition, translation, or TTS is designed to occur primarily on the end user's device. The Services may still process or store data needed for authorization and model management, including:
* Local PCM audio, recognized text, translated text, TTS audio, language direction, model path, model version, model status, channel, and sample rate.
* License ID, encrypted offline license file, model package version, model list, model root directory, download progress, extraction progress, and authorization status.
* Server-side license requests, model configuration checks, and model download metadata.
### 2.5 Diagnostics, logs, and observability data
Depending on configuration, SDK version, platform, and developer settings, the Services may process:
* Workflow logs, network status logs, error stacks, device diagnostic context, room number, UID, language direction, and error messages.
* Interface latency, error codes, exception information, RTC/RTM connection state, packet loss, subscription state, stage timing, crash, ANR, and resource metrics.
* Diagnostic audio or text artifacts, such as input PCM files, output TTS PCM files, ASR text, and MT text snippets, when diagnostic capture is explicitly enabled.
* Trace ID, translation mode, language direction, engine type, device type, room ID, failure reason, stability metrics, and performance metrics.
Diagnostic audio, translation text, exported logs, and support attachments can contain personal data or sensitive personal data. Developers should enable these features only for authorized testing, support, or troubleshooting, restrict access, apply retention limits, and remove unnecessary identifiers before export or upload.
## 3. How we use information
We use information for the following purposes:
* Provide, secure, operate, and improve the Services.
* Authenticate developers, validate SDK access, issue tokens, bind devices or installations, enforce quotas, and prevent replay or abuse.
* Provide online and offline AI translation, speech recognition, machine translation, TTS, room connection, messaging, and callback features.
* Manage offline licenses, model availability, model downloads, and SDK configuration.
* Maintain tenant isolation, role-based access, service entitlements, and developer account settings.
* Monitor reliability, latency, crashes, ANRs, resource usage, connection quality, packet loss, and service errors.
* Provide support, reproduce issues, respond to security reports, and resolve technical incidents.
* Process billing, subscriptions, invoices, usage limits, audits, and account administration.
* Comply with legal obligations, enforce agreements, protect rights, and respond to lawful requests.
We do not use end-user customer content to train generalized AI models unless your agreement, product setting, or separate consent expressly allows that use.
## 4. Cookies and similar technologies
When you visit Timekettle Developer websites, documentation, dashboards, account pages, or support channels, we may process device, browser, session, analytics, security, preference, and similar data through cookies or comparable technologies.
Cookies may help us keep you signed in, protect accounts, remember preferences, measure documentation performance, diagnose errors, and operate support features. Non-essential cookies are used according to applicable consent requirements. See our [Cookie Policy](/legal/cookie-policy) for more detail.
## 5. Permissions and platform disclosures
The Android SDK may declare `android.permission.INTERNET` to access authentication, room, online translation, model configuration, offline license, log, or observability services.
The Android SDK may declare `android.permission.ACCESS_NETWORK_STATE` to determine network connectivity and support weak-network handling, reconnect behavior, and diagnostics.
The Android SDK source policy states that the SDK itself does not declare `android.permission.RECORD_AUDIO` in its manifest. If a developer product records microphone audio and sends PCM audio to the SDK, the developer product must declare and request microphone permission and explain the recording purpose in its own privacy notice.
If an iOS developer product records microphone audio, the developer product must include `NSMicrophoneUsageDescription` in `Info.plist` and obtain permission before recording.
The iOS SDK source policy states that its Apple Privacy Manifest declares that it is not used for tracking and does not declare collected data types under Apple's privacy manifest categories. Developers remain responsible for App Store privacy labels, app privacy notices, backend data disclosures, third-party SDK disclosures, and permission prompts based on the final app behavior.
Where applicable law allows processing without separate consent, such as processing necessary to perform a contract, comply with legal obligations, respond to emergencies, or meet other statutory grounds, the developer must still apply data minimization and enable only the SDK capabilities needed for the configured feature.
## 6. How we share information
We do not sell end-user personal data or share it for cross-context behavioral advertising through the SDK.
We may share or make information available as described below:
| Recipient or component | Information that may be processed | Purpose |
| ----------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- |
| Timekettle backend services | Authentication requests, device binding data, tenant or installation identifiers, room requests, language configuration, online translation data, offline license requests, model configuration | Authentication, room creation, translation services, offline authorization, model management, and service operations |
| Agora RTC/RTM SDKs or services | RTC/RTM token, UID, room connection data, audio stream, message channel data, network state | Online audio transport, real-time messaging, and connection state management |
| CloudCare, FTMobile, or observability components | Trace ID, stage timing, error information, crash, ANR, resource metrics, logs, and quality metrics | Stability, performance, failure-rate, and service-quality monitoring |
| Developer app or developer backend | Developer-provided user identifiers, installation identifiers, business configuration, account state, authorization policy, and user requests | Business account binding, permission control, service enablement, and user support |
| Service providers | Hosting, infrastructure, security, analytics, payment, support, communications, and operations data needed to provide contracted services | Operate, secure, support, bill, and improve the Services |
| Authorities, transaction parties, or legal recipients | Information required by law, court order, regulatory request, merger, acquisition, financing, reorganization, or similar event | Comply with legal obligations, protect rights, and support corporate transactions |
Developers should disclose the relevant SDKs, service providers, purposes, data categories, permissions, and user rights paths in their own privacy policy and third-party SDK list.
## 7. International transfers and data location
Local SDK data is stored on the end user's device in app-private storage, platform key stores, user defaults, SDK diagnostic directories, model directories, or developer-configured storage paths.
Server-side data location depends on the developer's `networkEnvironment`, `networkBaseURL`, Timekettle deployment, real-time communication service configuration, observability configuration, and contract. Where personal data collected or generated in a specific jurisdiction is subject to localization or cross-border transfer rules, the developer is responsible for configuring the integration and obtaining required notices, consents, assessments, certifications, contracts, or approvals.
## 8. Retention
We retain information only for as long as needed for the purposes described in this policy, unless a longer retention period is required or permitted by law, contract, security needs, dispute resolution, or accounting obligations.
SDK-related retention depends on the data type:
* Tokens are usually retained until expiration, account logout, cache cleanup, or re-authentication.
* Offline licenses and model files are retained until deleted by the developer product, invalidated by authorization status, replaced by model updates, or removed following a user request.
* Diagnostic logs are subject to local SDK rotation. The source policy states that Android `sdk_diagnosis` and iOS `Library/sdk_diagnosis` logs currently use an approximately four-day local retention and rotation strategy.
* Diagnostic PCM files, TTS PCM files, text snippets, exported logs, and support attachments should be deleted when troubleshooting is complete unless a lawful reason requires longer retention.
## 9. Local SDK storage
Android SDK integrations may store online authentication session data, including `userToken`, expiration time, user, tenant, region, scopes, ClientID, package name, request tenant, and installation context.
Android integrations may also store device private keys in Android Keystore, encrypted offline license files such as `tmk_auth/offline_license.dat` in app-private storage, SDK diagnosis logs in internal or app-specific external directories, and diagnostic input PCM or output TTS PCM files when diagnostics are enabled.
iOS SDK integrations may store online authentication session data in `UserDefaults`, including `userToken`, expiration time, user, tenant, region, scopes, ClientID, Bundle ID, request tenant, and installation context.
iOS integrations may also store device private keys in Keychain, encrypted offline license files at `Application Support/.tmk/auth/offline_license.dat`, SDK diagnosis logs in `Library/sdk_diagnosis`, and diagnostic input PCM or output TTS PCM files when diagnostics are enabled.
When an end user logs out, withdraws consent, deletes an account, or asks to remove local data, the developer should evaluate and clean SDK authentication caches, offline licenses, model files, diagnostic logs, audio dumps, temporary files, exported files, backend user identifiers, authorization relationships, translation records, support tickets, and diagnostic attachments as required by law and the developer's own policy.
## 10. Security
We use technical and organizational measures designed to protect information processed through the Services. Current SDK and service controls include:
* Request signing, timestamps, nonces, and token mechanisms for network authentication.
* Redaction of sensitive log fields such as tokens, signatures, licenses, `client_secret`, and `Authorization` values.
* Android device private key storage in Android Keystore.
* iOS device private key storage in Keychain.
* Encrypted offline license storage in app-private directories.
* iOS offline license file protection and backup exclusion.
* Diagnostic log local retention and rotation.
Developers should also:
* Keep production AppSecrets, long-lived tokens, private keys, administrator credentials, `.env` files, and local configuration out of source repositories and client logs.
* Prefer server-side credential exchange for sensitive credentials where the product architecture allows it.
* Use production HTTPS domains and avoid shipping test base URLs, debug tokens, or verbose logging in release builds.
* Use low-identifiability or irreversible values for `externalUserId` and `installId` where possible.
* Restrict access to diagnostic files, crash logs, analytics backends, and support attachments.
* Maintain incident response, deletion, and user-rights workflows for the data their products process.
No internet or software system can be guaranteed to be completely secure. We and developers should continue to reduce exposure risks for audio, text, tokens, licenses, diagnostic files, and other sensitive materials.
## 11. End-user rights and developer responsibilities
Depending on applicable law, individuals may have rights to access, copy, correct, delete, restrict, object to, port, or withdraw consent for personal data. They may also have rights to close accounts or submit complaints.
Because end users usually interact directly with the developer product rather than Timekettle Developer, end users should normally contact the developer first. We will assist developers with lawful and verified requests as required by contract and applicable law.
If an end user withdraws microphone permission or stops using a translation feature, the developer product should stop recording, stop passing audio to the SDK, disconnect online rooms or channels where appropriate, and clear temporary audio or diagnostic files according to the product's policy.
## 12. Children's privacy
The Services are intended for developer use and are not directed to children as independent users. If a developer product is directed to children or is likely to process children's audio, text, account identifiers, or diagnostic materials, the developer must obtain required parental or guardian consent, provide child-specific privacy notices where required, and apply appropriate protections.
If a parent or guardian believes a developer product processed a child's information through the Services without required consent, they should contact the developer first. We may assist with deletion or anonymization after receiving a lawful and verified developer request.
## 13. Changes to this policy
We may update this policy when the Services, SDK features, processed data categories, third-party services, storage locations, permission behavior, or user-rights workflows materially change. Developers should evaluate whether they must update their own privacy policies, third-party SDK lists, app store privacy labels, and consent prompts.
If an update materially affects rights or processing rules, we or the developer will provide notice as required by applicable law. If a developer cannot comply with an updated processing requirement, the developer should stop using the affected Service capability.
## 14. Contact information
Developers can contact Timekettle through the support, account, security, or legal channels made available in the Timekettle Developer dashboard, documentation site, order form, or service agreement. If those channels are unavailable, contact `support@timekettle.co`.
End users should contact the developer product first because the developer controls the end-user relationship, app permissions, account deletion flow, and product-specific privacy notices.
For related terms, see the [Terms of Service](/legal/terms-of-service) and [Cookie Policy](/legal/cookie-policy).