Talkala Privacy Policy

Account, profile, and sign-in data

Talkala keeps the data needed to create, secure, and operate your account. Email/password accounts store password hashes, never plain-text passwords. Google sign-in is optional when configured and stores the Google identity details needed to connect that sign-in to your Talkala account.

• Account identity, email address, email-verification state, accepted policy versions, and account status.
• Password hashes, password-reset tokens, email-verification tokens, and request fingerprints used for security limits.
• Display name, avatar, notification preferences, country and layout preferences, and account settings.
• Google sign-in identity, name, email, and verified-email state when you choose Google sign-in.

Calling, wallet, number, and caller-ID records

Each call or wallet movement creates records so Talkala can show history, finalize amounts, settle disputes, and match events with Talkala's telephone partner (calling) and payment partner (wallet). Wallet activity is tracked as dated entries rather than silently overwriting earlier lines.

• Call-related records typically include timing, outcome, routing context, billed amount, identifiers from Talkala's calling partner needed for troubleshooting, and the destination dialed.
• Wallet-related records typically include balances after top-ups or charges, refunds, temporary reserves during active calls, and payment references tied to Stripe where applicable.
• Dedicated-number records can include the number owned, billing status through Stripe subscriptions, setup identifiers from Talkala's phone partner where needed for support, inbound SMS readiness, and number status.
• Caller-ID records can include numbers you authorize, verification results, identifiers from verification calls handled by Talkala's phone partner, verification status, and failure reasons.

Contacts, inbound SMS, referrals, and notifications

Talkala stores user-facing content when that content is part of an app feature. That includes contact-book entries, text-message bodies for inbound SMS, referral records, and notifications or email summaries needed to operate those features.

• Contacts can include names, phone numbers, company, email, website, city, notes, tags, favorite status, initials, avatar data, and last-contacted metadata.
• Inbound SMS records can include sender and recipient numbers, message body, timestamps, delivery status from Talkala's phone partner, identifiers needed for troubleshooting, message-length details used for billing, and billing totals.
• Referral records can connect a referrer, referred account, referral code, reward status, qualifying wallet top-up, and the credited reward linked to qualifying activity.
• Notifications can include category, title, body, whether you marked them read, links, outbound email progress, troubleshooting references from Talkala's mail provider where needed, bounce or spam-report signals from providers, and delivery errors.

Contact, support, and email content

Public contact forms and signed-in support requests process the information needed to route and answer the request. Contact and support emails pass through whichever transactional mail provider Talkala configures for outbound delivery.

• Public contact forms collect name, reply email, topic, message, anti-abuse token, and cooldown fingerprinting data.
• Signed-in support requests collect topic, priority, subject, reply email, message, signed-in identity, session email, and cooldown fingerprinting data.
• Account and notification emails can include operational details such as top-up results, caller-ID events, number events, referral rewards, low-balance warnings, and failed-call notices.
• Email delivery records can include provider reference IDs, whether the message succeeded, bounced, or prompted a spam complaint, error messages providers return, and whether Talkala attempted follow-up retries.

Browser, device, analytics, and anti-abuse data

Talkala processes browser and request data to keep sessions alive, remember preferences, measure aggregate public-page traffic, prevent abuse, and protect account flows.

• Essential cookies and browser storage support signing in, accepting policies during account creation, admin verification checks, themes, layouts, profiles, dialer-country preferences, and how public pages behave when you already have a signed-in session.
• Request fingerprints and rate-limit events help throttle sign-up, sign-in, password reset, contact, support, calling, number, wallet, and caller-ID flows.
• Optional Cloudflare Turnstile checks on public and account-security forms may use approximate connection details (such as IP address) and typical browser indicators required to distinguish real visitors from scripted abuse.
• Hosted analytics records aggregate page-view data without third-party analytics cookies.
• Coarse country signals can come from request context, calling context, payment context, or operational pricing context. Account records may keep first-seen and latest request country at the country-code level for support and security review; Talkala does not store raw IP addresses for that account-country feature.

Why Talkala processes this data

The main legal bases under the General Data Protection Regulation (GDPR) are contract necessity, legal obligations, legitimate interests, and consent where a specific optional choice requires it. The exact basis depends on the activity.

• Contract necessity: account access, calling, wallet balance, number subscriptions, inbound SMS, call history, support, and settings.
• Legal obligation: tax, accounting, payment, regulatory, dispute, and fraud-prevention records where applicable.
• Legitimate interests: service security, abuse prevention, rate limiting, operational diagnostics, routing controls, aggregate analytics without advertising tracking, and matching billing or call facts with contracted partners.
• Consent or user choice: optional communications or feature choices where the app presents an opt-in or setting.

Providers and recipients

Talkala uses a small provider set to operate the product. These providers process data only where their role is needed for the feature, infrastructure, security, or support workflow.

• Stripe: hosted checkout, wallet top-ups, saved payment-method summaries, number subscriptions, invoices, receipts, and billing portal.
• Twilio: browser voice connection, calls to ordinary landline and mobile networks, caller-ID validation, phone-number setup, inbound SMS delivery, status signals used to finalize durations and charges, and cost information needed for prepaid billing.
• Application backend services: databases, server functions, and operational processing for accounts, wallets, calling, support, contacts, messages, notifications, pricing, and other product records.
• Hosting and delivery: web hosting, application delivery, aggregate traffic measurement, deployment infrastructure, and static asset delivery.
• Cloudflare Turnstile: optional bot-detection checks on public and account-security forms.
• Google: optional Google sign-in when configured.
• Configured transactional email provider: transactional, support, contact, account-security, and notification email delivery.

International transfers

Talkala is operated from Spain, but the infrastructure and communications providers may process data in other countries, including outside the European Economic Area. Where required, those transfers should rely on the provider's published transfer mechanism, data processing agreement, adequacy framework, standard contractual clauses, or equivalent safeguards.

How long records are kept

Retention depends on the record type. Some app preferences can be cleared from your browser. Operational records can remain longer when needed for account access, billing integrity, tax or accounting duties, fraud prevention, dispute handling, security logs, aligning billed calls with carriers, or legal compliance.

• Browser preferences generally last until you clear browser storage, they expire, or the app overwrites them.
• Temporary policy-acceptance handoff cookies expire quickly. Admin verification cookies are short lived.
• Payment, wallet, call, number, SMS, referral, support, and security records can remain after a feature is disabled or an account is closed when they are needed for audit, billing, abuse prevention, or legal reasons.
• Account closure is not the same as deletion. Some records can remain because billing, calling, messaging, or support history may still matter.

Your privacy rights

Depending on where you live, you may have rights to access, correct, erase, restrict, object to, or receive a copy of personal data. You can also object to some legitimate-interest processing or withdraw consent where processing is based on consent.

• Start with the legal contact email or signed-in support when the request is account-specific.
• Talkala may need to verify your identity before acting on a request.
• Some records cannot simply be deleted on request because they are tied to billing integrity, fraud prevention, tax, dispute, phone-network records, or security obligations.
• If you are in Spain or the European Union, you can also raise concerns with your data protection authority. For Spain, that is the Spanish Data Protection Agency (AEPD).

Children and special categories

Talkala is not designed for children, and it is not designed to collect special-category data such as health, religion, biometrics, or political views. Do not include that kind of information in contact notes, support messages, or SMS unless it is genuinely necessary for your own communication.

Automated decisions and fraud controls

Talkala uses automated checks for rate limits, verification gates, pricing availability, account state, route restrictions, caller-ID validation state, and abuse controls. These checks can block a call, form submission, number purchase, wallet action, or account feature. They protect the service, but you can contact support if you think a block is wrong.