Kveo · Updated
Privacy policy
How Kveo handles personal data on kveo.no, in the customer portal and when delivering our services, including exactly what Google user data the Google Calendar integration in our booking systems accesses, stores and shares.
Who is responsible?
Kveo, organisation number 937 282 400, Stord, Norway, is the controller for website enquiries, customer administration, billing and our own security operations. Contact [email protected] about privacy or your rights.
When we host or process personal data on a business customer’s instructions, the customer is normally the controller and we act as processor. A separate data processing agreement must govern that work; this policy does not replace it.
What we collect and why
Enquiries: name, email, optional phone/company details and the project description, budget and timing you submit. We use these to respond and prepare an offer. Name and email are required to use the contact form; other contact fields are optional.
Customers and support: contact persons, account details, services, correspondence, support replies and uploaded files. We receive information from you, your organisation and service providers involved in delivering the service. Passwords are stored as hashes; configured two-factor authentication and access tokens support secure access.
Billing and operations: invoice/subscription details, payment status, service configuration, login/security events, IP addresses and API activity. SMS logs include the phone number and full message content. The AI usage ledger records the model, token counts, cost, request ID and time, rather than prompt/response bodies. Anthropic still receives the content sent to the AI service.
Legal bases
We use GDPR Article 6(1)(b) where processing is necessary to take steps at your request or perform a contract with you. For business contact persons, support administration and secure operation, we rely on Article 6(1)(f): our legitimate interests in responding to enquiries, delivering services and preventing misuse, balanced against your rights.
Accounting records are processed under Article 6(1)(c), legal obligation. Optional analytics uses consent under Article 6(1)(a) and the applicable cookie rules. You can refuse or withdraw that consent without losing access to the website or services. We use connection and approximate location information for delivery, security and language selection based on legitimate interests.
The Google Calendar integration
Kveo builds booking websites and back-end systems for businesses. Some of them, currently the Bowlit booking system at bowlit.no (the application shown on Google’s consent screen), can create a Google Calendar event for each booking so that staff see bookings in the business’s own Google Calendar. The Google connection is set up once by the business’s administrator, who signs in with a Google account and approves the permissions listed below. In this calendar integration, customers who book on the website do not sign in with Google and do not give us any Google permission.
Kveo is the developer of the Google application and is responsible for how it handles Google user data, as described on this page. The business that connects its calendar chooses the calendar, owns the connected Google account and is responsible for the booking data it holds about its own customers. kveo.no itself does not use Google sign-in.
Google user data we access
The application requests four permissions (scopes). Google shows each of them on its consent screen before you approve, and we use nothing beyond them. We do not access Gmail, Drive, Contacts or any other Google service, and we never receive your Google password.
| Permission (scope) | Type | What it is used for |
|---|---|---|
openid | Non-sensitive | Identify the Google account that is connected. |
https://www.googleapis.com/auth/userinfo.email | Non-sensitive | Read the email address of the connected account so the admin panel can show which account is connected. |
https://www.googleapis.com/auth/calendar.calendarlist.readonly | Non-sensitive | Read the list of calendars (ID, name, whether it is the primary calendar, and your access role) once during setup so the administrator can choose the calendar for bookings. Only calendars the account can edit can be selected. |
https://www.googleapis.com/auth/calendar.events | Sensitive | Create, update and delete the calendar events the application makes for bookings and blocked times in the chosen calendar, and look those events up by booking code so no duplicates are created. |
What we receive and store:
- Email address of the connected Google account: stored while the account is connected and shown in the booking system’s admin panel.
- OAuth tokens: the refresh token is stored encrypted. Access tokens are requested from Google when needed and are not stored.
- Calendar list: fetched on demand to show the calendar picker and not stored. Only the ID and display name of the one calendar chosen are stored.
- Calendar events: the application writes events containing the booking code, activity, unit number, number of people, the booking customer’s name, phone number and email, an optional comment, the booking status, the time and the venue address. To find or check an event it created, it asks Google for events with that booking code or event ID and reads the match only to confirm it; we store only Google’s event ID with the booking. We do not browse, copy or store other events in your calendar.
- The permissions Google actually granted, timestamps of the last successful check and a shortened error message from Google if a call fails. The connected account’s email address and the name of the administrator who connected it are also written to the server’s operational log when the connection is made.
The booking details written to the calendar are personal data about the business’s customers. They come from the booking form, not from Google; copying them into the calendar is the feature the business has chosen. The business decides who has access to its Google Calendar; the application never changes calendar sharing.
How we use Google user data
We use Google user data only to provide the user-facing feature the administrator asked for: showing which Google account is connected, letting the administrator choose a calendar, and creating, updating and deleting the booking and blocked-time events in that calendar when bookings are made, changed or cancelled. Every six hours, and when the admin panel is opened, the application also asks Google for a fresh access token to check that the connection still works and to detect revoked access; this reads no calendar content. We do not use Google user data for any other purpose: no advertising, no profiling, no analytics, no sale and no training of AI or machine-learning models. Google user data is not sent to AI services.
Our staff do not read your Google user data unless you give explicit permission for specific items (for example in a support case), it is necessary for security purposes such as investigating abuse, it is required to comply with applicable law, or the data has been aggregated and anonymised for internal operations.
Legal basis: for the administrator’s Google account details, our legitimate interest in providing and securing the integration the business has asked for (GDPR Article 6(1)(f)); for booking details placed in the calendar, the business’s agreement with its customers and its own legal basis as controller.
Sharing, transfer and disclosure of Google user data
We do not sell Google user data, and we do not transfer or disclose it to third parties for purposes other than providing the features described above. Google user data is shared only with: Google itself (the booking events are sent to the Google Calendar API over an encrypted connection); the infrastructure providers that host and run the application on our behalf under their service terms (Gigahost for the server and database, Cloudflare for network delivery and protection); authorities or others when required by law or needed to protect the security of users and the service; a successor in a merger or acquisition, with notice to you and subject to this policy; or anyone else with your explicit consent.
Google user data is not shared with advertisers, data brokers, analytics providers or AI providers.
Limited Use of Google user data
The use of information received from Google APIs will adhere to the Google API Services User Data Policy (https://developers.google.com/terms/api-services-user-data-policy), including the Limited Use requirements.
Kveo’s use and transfer to any other app of information received from Google APIs will adhere to the Google API Services User Data Policy, including the Limited Use requirements. We use the data only to provide and improve the user-facing calendar feature described above.
We never use or transfer Google user data for advertising of any kind, including targeted, personalised, retargeted or interest-based advertising; never sell it to data brokers or information resellers; never use it to determine credit-worthiness or for lending purposes; and never use it to build databases unrelated to the feature you use.
We do not use Google user data, including data obtained through Google Workspace APIs, to develop, improve or train generalised or non-personalised AI or machine-learning models.
How we protect your data
All connections to our websites and the Google OAuth flow use HTTPS (TLS). The Google refresh token is encrypted at rest with AES-256-GCM; the encryption key is held in the server’s environment configuration, not in the database or the source code. Tokens and the OAuth client secret are never sent to the browser and are not written to logs. Passwords are stored only as hashes.
The OAuth flow runs on the server and uses a random one-time state value to prevent forged callbacks. Only a logged-in administrator of the booking system can start, change or disconnect the Google connection, and changes require a CSRF token. We keep software up to date and will notify affected users and Datatilsynet of a personal data breach as required by law.
Revoking access and disconnecting
You can stop our access at any time in two ways:
- In the application: the administrator opens Admin → Integrations and selects “Disconnect from Google”. The application asks Google to revoke the token, and deletes the stored token, the account email and the calendar choice immediately.
- In your Google Account: remove the application at https://myaccount.google.com/permissions. The application finds out the next time it contacts Google (at the latest at the next booking or the six-hourly check), stops writing to the calendar and marks the integration as needing reconnection.
Events already created in the Google Calendar are not deleted when you disconnect. They belong to the calendar, and its owner can delete them in Google Calendar. While the integration is connected, cancelling or deleting a booking in the booking system deletes its event from the calendar.
Retention and deletion of Google user data
The refresh token, the account email and the calendar choice are kept only while the integration is connected and are deleted when the administrator disconnects it. Access tokens and calendar lists are not stored. Google’s event ID is kept with the booking record, and the booking record itself follows the retention rules of the business’s own privacy policy; the event content in Google Calendar stays until the calendar owner deletes it.
To have the Google user data we hold deleted, disconnect in the application or email [email protected]. If you revoke access only in your Google Account, the stored encrypted token is not removed automatically, so please also disconnect in the application or email us. We complete deletion within 30 days. Encrypted copies may remain in routine database backups for a limited period (up to 30 days) and are overwritten on the normal cycle. We keep data after a deletion request only where the law requires it or to resolve an ongoing security incident, and only as long as necessary.
Processing outside the EEA
Some providers operate internationally, including in the United States. Processing location and provider role depend on the service and contract. Providers may be processors for delivery and separate controllers for purposes such as their own legal duties or fraud prevention.
Transfers outside the EEA require a valid GDPR Chapter V basis, such as an applicable adequacy decision or standard contractual clauses with the necessary assessment and supplementary safeguards. Contact us for the safeguards and processing locations applicable to your service, or to request a copy. A provider privacy link alone is not a data processing agreement or a transfer safeguard.
How long data is kept
Enquiries are kept while we handle the request and any resulting follow-up or agreement. Customer accounts, support history, SMS content and operational logs are kept only while needed to deliver the service, investigate faults or misuse, settle billing or establish and defend legal claims. Retention depends on the service, the nature of the record and any outstanding issue; ask us for the retention assessment for your data.
Accounting documentation that must be retained is normally kept for five years after the end of the financial year. Other statutory periods may apply to particular records. Ending a service does not immediately erase records that must be retained. Data handled on a customer’s instructions follows the return/deletion terms of the data processing agreement.
Your choices and rights
You may request access, correction, deletion, restriction and, where applicable, data portability. You may object to processing based on legitimate interests and withdraw consent at any time; withdrawal does not affect prior lawful processing. We may need to verify your identity and normally respond within one month.
Email [email protected]. If the data belongs to your organisation’s service, contact that organisation as controller; we can help route the request. You can complain to the Norwegian Data Protection Authority, Datatilsynet, at datatilsynet.no. This app does not use AI to make solely automated decisions about you with legal or similarly significant effects.
These rights follow from the GDPR and the Norwegian Personal Data Act (personopplysningsloven). You can also manage what Google shares with applications in your Google Account at https://myaccount.google.com/permissions.
Changes to this policy
We update this policy when services or processing change. The date at the top identifies this version. Where required, we will provide a separate notice of material changes.
If we change how an app uses Google user data, we will update this policy, notify affected users in the app or by email before the change takes effect, and ask for your consent again before using Google data for a new purpose.
Providers and data sharing
The following providers support our website and services. Customer-specific providers receive data when the relevant service is used; browsing the website does not send your data to every provider. Links lead to the providers’ own information.
- Gigahost
- Hosting of the website, customer portal, database and uploaded support files. Data stored in those services is processed on the hosting infrastructure.
- Cloudflare
- DNS and domain administration. When Cloudflare proxy, CDN or security features are enabled, Cloudflare also handles visitor IP addresses, request URLs, browser details and security events to deliver and protect traffic. Security cookies depend on the features enabled.
- Microsoft 365 / Entra ID
- Email and support correspondence, including sender and recipient addresses and message content. Entra ID handles Microsoft administrator sign-in and supplies identity/profile information, including a profile photo when available.
- Stripe
- Customer contact details, subscriptions, invoices and payment status. Payment details are entered in Stripe’s hosted payment/billing pages; this app does not store full payment card numbers.
- Fiken
- Customer/company details, billing addresses, invoice lines, amounts and payment status for invoicing and accounting.
- GatewayAPI
- SMS recipient phone numbers, sender ID, message content and delivery information. Messages are also passed through telecommunications operators. The configured platform is normally gatewayapi.eu; the service can also use gatewayapi.com.
- Anthropic / Claude
- Prompts, conversation messages, system instructions and other content submitted to the AI gateway, plus generated responses and usage information. This applies both with our key and with a customer’s own Anthropic key.
- Better Stack
- Monitored service names, URLs, IP addresses and availability/incident information for uptime monitoring and status pages. Do not include personal information in public service names or incident notices.
- Google Analytics
- On public pages using analytics, browser/device details, pages visited and interaction information are processed only after consent to statistics. Google receives connection information when its script is loaded.
- Google Auth Platform / Google Calendar API
- Google Calendar API and Google Auth Platform (consent screen, token and revocation endpoints). Used only by the Google Calendar integration in booking systems we build (currently Bowlit). Google receives the booking events the application writes to the calendar the administrator chose, plus the OAuth requests needed to keep the connection working. The visitor-facing website does not use Google sign-in.
- ip-api.com
- When a visitor opens the root or a legacy redirect without a saved language choice, the server sends the visitor’s IP address to look up country/region and suggest a language. The current lookup uses HTTP. Opening a language-specific URL directly avoids this lookup.