Privacy notice
How Dikaya handles accounts, prompts, answers, payments and cookies. Administrator access, external processing, retention and deletion limits.
Version:
Key points
- Prompts, answers and usage records are stored; this is not a zero-logging service.
- The administrator can access service records through protected tools, including private Telegram notifications.
- Deleting a conversation or account does not automatically erase payment, moderation, notification or backup records.
Scope and contact
This notice describes data handling by the Dikaya website, browser chat, API and account support. It covers the service at https://dikaya.cloud and the records needed to operate it. Service information and the available contact route are published on the contact page.
Data questions, requests to correct information and deletion questions are handled through the account Support section. The contact page explains how to use it and that no separate public email is currently published. A request may require enough information to confirm which account and records it concerns; do not send passwords or full keys.
What information is processed
Account records include username, password hash, key credentials/settings, balance, account status, timestamps and session records. Passwords are hashed with individual salts; this does not mean that every other record, prompt or key is encrypted at rest.
Browser chat history contains conversation titles, selected models and messages. Service logs can retain text from requests, answers, statuses, errors, token counts, charges, reservations and request identifiers. Support messages and replies are also stored. Images or URLs supplied in a request are processed to carry out that request; text descriptions can be retained by the image bridge.
Payment records can include invoice identifiers, network, public wallet addresses, amounts, payment references, transaction identifiers and confirmation status. Dikaya does not need your private wallet keys or recovery phrase. Public blockchain records are not controlled or erased by deleting a Dikaya account.
Network infrastructure processes IP addresses and technical connection data to deliver and protect the service. Application login and demo controls use derived network/device identifiers. This is not a claim of complete anonymity: account, request and payment records can still be associated with each other.
Why the service uses these records
Records support login, model processing, conversation history, prepaid accounting, payment confirmation, manual moderation, abuse prevention, operational diagnosis and customer support. They also help reconcile interrupted requests and avoid duplicate payment credit.
A separate first-party acquisition feature records a tagged campaign or referrer hostname and can link it to registration and confirmed payments. Within this feature a referrer is stored as a hostname, not its full path, URL parameters or IP address. This limited statement does not describe all technical processing by network infrastructure.
Cookies and browser storage
The application uses the records below. Lifetimes describe configured cookie/session expiry, not guaranteed deletion of all related server records. A session can end earlier after logout, a ban, deletion or another access restriction.
You can inspect or delete cookies and site storage through your browser. Disabling session cookies prevents normal login; deleting a device cookie does not reset server-side demo eligibility. Deleting an acquisition cookie does not erase a source already attached to registration, and a later qualifying visit can create a new cookie.
| Name | Purpose | Configured lifetime |
|---|---|---|
| dikaya_session | Signed-in account access | Up to 30 days |
| dikaya_device | One-time demo and abuse prevention | Up to 365 days |
| dikaya_acquisition | First tagged acquisition/referrer source | Up to 30 days |
| dikaya_draft (sessionStorage) | Move a draft from the landing page to the composer | Removed after successful transfer; otherwise browser tab-session storage |
Who processes or can access information
Prompts and necessary context are sent to external model-processing infrastructure to produce an answer. Hosting, network protection and payment-confirmation infrastructure process information needed for their respective tasks. Requests with an image can involve a separate image-to-text model step. This notice does not promise processing only in one country or an independently verified no-retention/no-training arrangement for every external component.
The service administrator can access stored records through protected administrative tools. Request/answer logs, payment events and support notifications can also be delivered to a private Telegram bot/chat for administration. This is not public publishing, but it is external processing rather than storage only inside your account.
The site uses Cloudflare for network delivery/protection. Its protection layer may use its own technical cookies or challenge mechanisms; these are separate from the application cookies listed above. App-level Turnstile can be enabled when configured; adding this notice does not itself enable it.
Retention, deletion and backups
You can delete a browser conversation using its delete control. This removes that conversation from the active chat history; it does not automatically delete the separate service moderation record or an already delivered private notification.
Confirmed account deletion removes sessions, browser conversations/messages, active support history and image-description cache, clears the password, invalidates the key and prevents normal access. A deletion tombstone, payment/usage/reservation/moderation records and the balance acknowledged at deletion can remain for audit and reconciliation. Some retained records can still contain a previous username or request text.
Backups and previously delivered private notifications are not automatically rewritten by account deletion. A single automatic deletion period for all chat, payment, moderation and backup records is not currently configured. Do not interpret cookie expiry or account deletion as a promise to erase every copy within a stated number of days.
For embedded image data the bridge uses a per-key cache of text descriptions with a 24-hour validity period. Expired entries are removed during bridge processing; the expiry is not a guarantee that every physical copy or backup is deleted at that instant. Mutable HTTP-image URLs are not cached by this feature.
Your choices and requests
You can review account data and chat history, rotate your API key, delete individual conversations and request confirmed account deletion through the available controls. For a correction, explanation of a charge or a separate data request, use Support and identify the relevant record without sharing secrets.
Only submit material needed for the task, and remove third-party personal information or secrets that are unnecessary. Request processing is not a guarantee that the response is accurate or that submitted material stays exclusively on your device. Browser and third-party client settings can also affect what context is sent.
A request for deletion or correction is reviewed alongside payment/audit requirements and the actual technical records. This notice does not override applicable rights or promise an unimplemented universal export/erasure endpoint, a response SLA or immediate deletion across all external systems.
Changes to this notice
The version date is shown on this page. The notice should be updated when material data handling changes. Publishing this text does not add a new tracker, enable a new bot, alter existing financial records or record a new consent action on your behalf. Questions can be sent through the contact route.
Practical guides
Guides on code, writing, GLM-5.3 and API integration (Russian)
Source: official Dikaya model catalogue, published rates and account/demo conditions. Pricing · Documentation
Facts reviewed: . Publisher: Dikaya.