Privacy Policy

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.

​

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, metadata, diagnostic materials, and other integration 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 application identifiers, application name, platform metadata, 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 stored 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:

​

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.

​

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. If this practice changes, we will provide notice and obtain required authorization where applicable law requires it.

​

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 for more detail.

​

5. Permissions and platform disclosures

​

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: 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 selected service environment, configured service endpoints, 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 retention and rotation periods that may vary by SDK version, platform, configuration, and developer settings.
• 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

​

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 developers control the end-user relationship, app permissions, product account flows, and product-specific privacy notices, end users should contact the developer product 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, legal, or privacy channels made available in the Timekettle Developer dashboard, documentation site, order form, or service agreement. If those channels are unavailable, developers may submit privacy-related requests to 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 and Cookie Policy.