Roomy360

Roomy360 privacy policy

This policy describes the data Roomy360 processes for apartment searches, enquiries, bookings, account workspaces and connections to ChatGPT or Codex. The Roomy360 plugin and the website's built-in AI features are described separately because they exchange different data.

Last updated: 4 November 2026

1. Controller and contact details

360Solutions LLP (BIN 190840028253)

Republic of Kazakhstan, Akmola Region, Kosshy city, Lesnaya Polyana microdistrict, building 20

support@roomy360.com

2. Scope and sources of data

This policy covers roomy360.com, its account workspaces and Roomy360 tools connected to OpenAI products. Data comes from your forms and messages, tool calls, actions by hosts and authorised staff, and technical browser requests. For company bookings, a colleague may provide your trip information.

OpenAI's policy governs processing in ChatGPT and Codex, including conversation history. Email, payment and other external services also apply their own policies to processing in their services. This page describes Roomy360's processing.

3. Data we process

Account and access: name, email, phone, user identifier, role, authentication and permission information. Password sign-in uses a protected representation of the password; connections store information about grants, token expiry and revocation. Linking Telegram also involves the linked chat identifier.

Search and bookings: property and unit, dates, adults, children and infants, price limits and other selected conditions; guest name and phone, email where present, booking participant identifiers, statuses, prices, discounts, confirmation and payment deadlines, and actual check-in. Manager enquiries also contain language, source, submitted text, assignee, processing comments and a booking link. Booking conversations and support enquiries include messages and attachments you provide.

Properties and company bookings: host and company details, contacts, bank details, personal or business identification numbers where needed, property address, photos, descriptions and calendar; contracts, invoices and stay documents. Receipt and host payout records contain the amount, date, bank reference or payment document number and the staff member recording the transaction. Creating a booking request does not itself process a payment.

Technical data: IP address, request time, path, method, identifier and duration, errors and notification delivery information; cookies and local preferences. Enquiry sources can include UTM tags, referring domain and the site, chatgpt or manual channel. AI and analytics data are explained below. Do not put passwords, full card details or identity documents in search wishes or ordinary messages.

4. Why data is used

Data supports sign-in and access controls, search and price calculation, sending requests to the selected host, arranging stays, messaging and support. Company and financial information supports contracts, invoices and documents, records of actual receipts, refunds and payouts, dispute resolution and applicable document retention obligations.

Enquiries and booking stages are recorded for processing and operational reporting, including linking sources to enquiries or bookings. Technical records help resolve failures, deliver notifications, limit abuse and protect accounts. Optional web analytics requires a separate choice; consent to it is not a condition of submitting an enquiry or making a booking.

Roomy360 does not use guest data for advertising mailings, share it with advertising partners outside service delivery, or use it to train its own AI models. This does not remove the described exchange with OpenAI when AI features are used or external services’ processing under their terms.

5. Connecting Roomy360 to ChatGPT and Codex

When connecting, you sign in to Roomy360 and grant the permissions shown: search, booking requests and reading bookings accessible to your account. Roomy360 receives the parameters of the individual tool call and information needed to check access, rather than your entire OpenAI conversation. Text that you or the assistant include in tool arguments forms part of that call.

Tool results are returned to the OpenAI product and may appear in the conversation. Booking requests include guest contacts; booking lists contain records accessible to the connected account. Only connect an account whose data you are entitled to share in that conversation. Your Roomy360 password is not a booking tool argument.

OpenAI handles its copy under the terms of the product you use and the OpenAI privacy policy. OpenAI conversation settings and deletion do not replace a separate request to delete records held by Roomy360.

6. Data exchanged by plugin tools

search_stays accepts city, dates, adults, children and infants, budget, bedrooms and a result limit. It returns matching published properties and their attributes. get_property accepts a property identifier or page slug and returns descriptions, photos, location, units, prices and rules. get_availability accepts a property and period and returns availability and prices by date. These calls support choosing accommodation.

create_quote accepts the property, unit, dates and guest counts and returns the stay calculation, discounts and total. It creates no booking and charges no money. request_booking accepts those parameters, guest name and phone and source; it links the request to the signed-in account, saves it and sends it to the selected host. The host receives information needed to handle the request and arrange the stay. The tool itself does not process a payment.

request_booking and list_my_bookings return fields from records accessible to the account: booking, property, unit and participant identifiers, guest name and phone, traveller email where present, dates and guest counts, statuses and change times, prices and discounts, source, confirmation, cancellation, refund, payment and check-in information. Populated fields can also include the company identifier, corporate invoice deadline and amount, recorded receipts, payouts and internal calculation components. list_my_bookings does not ask for another person's contacts and is not a service for finding strangers' bookings by phone.

These tools do not request card details or passport scans and do not execute payments, refunds or electronic invoice issuance. A booking status alone is not evidence of payment. Results come from Roomy360 and are not a promise of host approval.

7. AI search and chat on the website

When AI search is available and you submit your wishes, the site sends OpenAI your text, current search conditions, language and current date for date interpretation. The server validates the resulting filters and searches Roomy360 inventory. This search does not create a booking request. The original text is not included in search result URLs or web analytics events.

In the website's built-in AI chat, OpenAI receives the submitted messages, conversation context included in the request and results of tools available to that chat. These may contain account and booking information needed for the response. This differs from the plugin connection, which exchanges individual tool arguments. Website chat history is stored locally in the browser per user; you can delete it in the chat interface or by clearing site data. This does not delete a booking or a provider's copies.

Public AI search rate limits use a temporary session identifier and counters whose keys are cryptographically derived from IP and session identifiers. Those counters do not need the request text. OpenAI processing is also governed by its terms; we do not promise that an external provider retains no data.

8. Who may receive data

When WhatsApp sign-in is available and you request a code, Roomy360 sends Meta/WhatsApp the recipient phone number, one-time code and template language to deliver the message. We receive the message identifier and delivery updates. This may involve processing outside Kazakhstan. You choose this sign-in method; using it does not give consent to marketing messages. The code is valid for 5 minutes; Roomy360 stores a protected representation of the code rather than the code itself. The verified phone identity is stored separately from the profile contact number. Processing by WhatsApp is also covered by the WhatsApp Privacy Policy.

Roomy360’s primary infrastructure is hosted on a Cloud24 VPS in Kazakhstan. The infrastructure provider handles the hosted data and files. This does not mean that all copies held by external recipients are located in Kazakhstan.

The selected host receives guest contacts and stay details to review a request and arrange check-in. Authorised Roomy360 staff receive data for enquiry handling, booking support and financial records. For company bookings, authorised users of the relevant company can access trip details and documents within their workspace permissions.

Resend is used for email and receives the recipient address, message contents and delivery information. Telegram is used for linked notifications and receives the chat identifier and message contents. An email to a manager may contain contacts, dates and wishes from your enquiry. The recipient’s email service also processes the delivered message.

OpenAI receives the plugin call data and data from website AI features you use, as described above. Google receives Google Analytics data only when you allow analytics. These providers may process data outside Kazakhstan.

Company details are filled in using a BIN lookup through the data.egov.kz open data portal: the request sends the BIN, and the register returns the company name, legal address, director information, status and activity classification. These details support filling in and checking company information, not searching for its employees’ bookings.

Electronic invoices are processed using Kazakhstan’s IS ESF system. The relevant document contains seller and buyer details, business or personal identification numbers, addresses, contract details, date, document number, amounts and a service description. The description can contain the booking number, property name, stay dates and guest name; the document also contains operator or signatory information and seller bank details where populated. IS ESF and the document recipient receive these data. This is a separate document workflow, not an automatic transfer with every search or booking request.

Internet acquiring is not currently connected: the site and plugin do not collect card details for an online charge. If payment is made by bank transfer, the bank processes it under its terms and Roomy360 records the payment information received. Data may be supplied to authorities or other authorised recipients where an applicable lawful basis exists.

9. Cookies, enquiry sources and analytics

The site uses authentication and security cookies and local interface preferences. Blocking necessary cookies may prevent sign-in. Analytics preferences are stored in the browser. Google Analytics loads only with consent and receives usage events, page information and browser or device data according to its configuration. Roomy360 events do not include names, phones, email addresses, company banking details or free text from forms or AI requests.

With consent, first and last non-direct source history is stored in the browser for up to 30 days. Without consent, that history is not stored, but current UTM tags and the referring domain may be recorded with an enquiry or booking for operational reporting. This does not enable Google Analytics without consent.

You can change your choice in Analytics settings. Withdrawal stops the site sending analytics events and clears local source history; it does not delete existing enquiries, bookings or data already received by an external service. Essential booking actions continue to work.

10. Storage and retention

The following schedule and rules have been approved. Rollout is staged: automatic deletion under this schedule is not enabled yet; a report-only checking mode has been prepared. These periods govern cleanup and request handling, and are not a statement that existing records have already been erased. Until rollout is complete, records may remain beyond these periods; support can review and process a deletion request. This policy will update the rollout status after configuration has been verified.

Accounts: review after 24 months without verified activity. A warning is sent from month 23; deletion can take place no earlier than 30 days after actual delivery and only if there are no active obligations. A new sign-in resets the warning. Where a legacy account has no reliable activity date, its registration age alone does not justify deletion; a separate review is required.

Unconverted enquiries: 90 days after the last substantive customer contact, or creation if there was none. Staff status changes or notes do not extend the period. Rejected, cancelled or expired unpaid requests: 90 days after final closure. Booking contact details and conversations: 12 months after checkout or final settlement, whichever is later. Outstanding payments, refunds, host payouts and disputes are checked before cleanup.

Financial and source accounting documents are separated from conversations. The baseline archive review is 5 years after the end of the year in which the relevant transaction was completed. This is not an unconditional destruction date: staff classify the document, check its mandatory period and any audit or dispute; a longer mandatory period takes precedence. Once retention is no longer justified, data is erased or irreversibly anonymised. A nameless record still linked to a document or identifier is not anonymous.

Access and error logs: 30 days; security records: 90 days. Sent email and Telegram notification payloads in queues and delivery logs: 30 days after sending; permanently failed queue records: 30 days after creation. In-app notifications: 90 days. Stuck deliveries require separate review and are not counted as successful deletions. Infrastructure configuration is needed to enforce server log periods.

OAuth usage periods: access tokens 15 minutes, refresh tokens up to 30 days, authorisation codes 10 minutes. Expired token and code records are scheduled for cleanup 30 days after expiry; revocation records are not removed before the token expires. The public AI search cookie lasts 24 hours; its Redis counters expire 48 hours after their last update.

Local AI chat history has a 30-day retention rule from the last user message. Automatic expiry is not enabled yet; once enabled, cleanup occurs on the next use of the site, not remotely in a closed browser. Until then the limit is 40 conversations and 80 messages per conversation; you can delete history yourself. Source attribution with analytics consent lasts 30 days. The selected target for GA4 event and user data is 2 months, with activity-based reset disabled; application of that Google setting still needs verification. Analytics choices and interface preferences remain until changed or site data is cleared.

Backups: a target of 30 days from creation. Configuration and actual rotation of Cloud24 and other stored copies still need verification. After a restore, confirmed erasures must be replayed from a separate protected journal before access is reopened. The journal keeps minimal identifiers and operation evidence until all recoverable copies have been verified as expired; it does not contain erased conversations. Immediate removal from every backup is not promised before verification.

Where a lawful retention exception applies, its reason, responsible person and next review date are recorded; review is due within 90 days. A review does not automatically remove a lawful hold. Exceptions should cover only necessary records and end when their basis ends. Retention by OpenAI, Google, Resend, Telegram, the IS ESF system and other recipients also depends on their rules and obligations; erasure in Roomy360 does not erase all independent copies. Support separately reviews applicable provider requests.

11. Data protection

The application uses authentication checks, account and role access controls, protected tokens and rate limits. Use HTTPS addresses and do not share your password in chat. Technical logs can contain IP addresses and request paths, so do not place personal data in arbitrary URLs. No protection measure provides an absolute security guarantee.

12. Your choices and data requests

To request access, correction, deletion, restriction of processing or withdrawal of consent, contact support@roomy360.com. Identify your account and request; do not send your password or full card details. Proof of account ownership may be required to avoid disclosing data to someone else. If active obligations or applicable requirements prevent deletion of some records, this should be explained when handling your request.

You can disconnect the plugin in your OpenAI product's connection settings. For revocation on the Roomy360 side, contact support and identify the connection. API keys you created in your account can be revoked in the keys section. Disconnecting does not cancel a booking, delete OpenAI history or constitute an account deletion request.

You can disable optional analytics in site settings and remove local AI chat history in chat or your browser. Use OpenAI privacy controls for its copies of conversations and data. When providing another guest's or employee's details, make sure you are entitled to provide them for booking.

The Roomy360 operator handles requests through support. Our target is to acknowledge receipt within 1 working day and fulfil an ordinary justified erasure request within 7 calendar days after identity verification, unless the law requires a shorter period. If verification or active obligations prevent erasure, support explains the reason and next steps. Requests are registered and checked across separate stores; deleting a profile alone does not complete a request. Sending an email does not itself trigger automatic cleanup.

13. Children's data

The service is intended for adults arranging stays. Searches and requests can include the numbers of children and infants to check accommodation suitability; plugin tools do not ask for their names or documents. An adult providing additional information about a child for a stay must be entitled to do so.

14. Policy updates

The revision date appears on this page. The policy is updated when purposes, data categories, recipients or retention arrangements change. Publishing a revision does not replace separate consent where new processing requires it.