Bink and Google Calendar

What Bink is

Bink is a tool for independent professionals — coaches, therapists, consultants, tutors, photographers. Each user gets one public page where clients find them, book an appointment and pay. Bink also handles the accounting side of what they earn: invoices, customer records and tax figures.

The Google Calendar integration is optional. It exists so that a user’s Bink booking page and their real calendar never disagree, and so that the user can check and adjust their own schedule by asking Bink’s assistant. A user who does not connect a calendar can still use every other part of the product; bookings are simply kept only inside Bink.

What the integration does

Once a user connects a calendar and selects it, Bink uses it for four things:

1. Shows real availability. Before displaying bookable time slots to a visitor, Bink reads the events already on the selected calendar and removes the times in which the user is busy. For this Bink reads only the start, end, status and busy/free flag of each event — never titles, guests or descriptions — and visitors never see anyone’s existing events. No AI model is involved in this.
2. Puts each booking on the calendar. When a client books, Bink creates one event on the selected calendar with the service, the client’s name and the location. If the client left an email address they are added as a guest. If the user chose Google Meet as the meeting place, Bink asks Google to attach a Meet link to that event. If the booking is rescheduled, Bink replaces that event with one at the new time; if it is cancelled, Bink deletes it. Registrations to a Bink event page work the same way, as guests on a single calendar entry, and if the user edits the event page Bink updates that entry. No AI model is involved in this either.
3. Answers the user about their own schedule, only when asked. When the user asks Bink’s in-app assistant something like “what do I have this week?”, Bink lists the upcoming events on the connected calendar — title, start and end, location and guest emails, up to 50 per request — and uses them to answer. Only if the user explicitly asks, the assistant creates a new event or moves an existing one to a new time. To produce the answer, these events are sent to Bink’s AI provider, Mistral AI SAS, which processes them on Bink’s behalf on a plan where training on submitted data is switched off. Bink does not store them. This is the only path on which calendar data reaches a model, and the AI and machine learning section below describes it in full.
4. Lets the user choose the calendar. At connection time Bink lists the calendars in the account so the user can pick the one to sync — their own, or a calendar shared with them such as a joint practice agenda.

The permissions we request, and why

Bink requests 3 scopes and no others. Two are sensitive; the third is not. For each one, this is what it allows and why a narrower scope would not work.

What Bink does not do

• Bink does not create, rename or delete calendars in the user’s account.
• Bink does not change the sharing or permission settings of any calendar.
• Bink never deletes events it did not create. The only change it makes to an event it did not create is moving it to a new time, and only when the user explicitly asks the assistant to.
• Bink does not access any other Google service — no Gmail, no Drive, no Contacts, no Photos.
• Bink does not show a user’s calendar contents to anyone else. Visitors to a booking page see free and busy times, never event titles, guests or details.
• Calendar data is never sold, never used for advertising, and never used to develop, improve or train any generalized AI or machine-learning model — by Binatomy or by any of its providers.

How to connect

1. Sign in to Bink and open Settings → Integrations.
2. Select Connect Google Calendar.
3. Google shows its consent screen with the permissions listed above. The consent is granular: each permission has its own checkbox and can be refused.
4. Choose which calendar Bink should use.

If the user refuses the calendar events permission, the connection is not saved at all and no calendar data is read or written — Bink tells the user which permission is missing instead of showing the account as connected. If the user grants events but refuses the calendar list, the sync works and Bink says so, but the calendar picker is unavailable.

How to disconnect

There are two ways, and either is enough:

• From Bink. In Settings → Integrations, select Disconnect. Bink asks Google to revoke the token and then deletes the stored connection — tokens included — from its database.
• From the Google account. At myaccount.google.com/permissions, remove access for Bink. The stored tokens stop working immediately.

Disconnecting stops the sync, and the assistant’s access to the calendar, from that moment on. Appointments Bink has already written to the calendar stay where they are — they are the user’s own events, and removing them would silently empty a working agenda.

What happens to the data

For each connected user Bink stores the OAuth access and refresh tokens, their expiry, the list of permissions Google actually granted, the identifier of the selected calendar, the email address of the connected account and one availability preference. These are held in Bink’s database, hosted in the European Union, and are transmitted only over TLS.

Bink does not keep a copy of the user’s calendar. For availability, existing events are read at the moment a visitor asks for available times, used to compute which slots to hide, and not stored. Events read by the assistant are used to answer that request and are not stored either; the assistant may keep a short work-related note in the account memory, which the user can see in their data export and ask to delete. What Bink does store is the bookings made through Bink itself and the identifier of the calendar event it created for each one, so it can update or delete that event later.

When a user disconnects the integration, the token is revoked with Google and the whole stored connection is deleted. When a user deletes their Bink account, the connection is deleted with it. To request deletion of any data obtained from Google, write to info@binatomy.com.

Who we share Google user data with

Data obtained from the Google Calendar API is disclosed to the following recipients, and to no one else. Each of them, except the last — which the user brings themselves — processes that data as a processor, on Binatomy’s instructions and on the terms agreed with it.

Beyond those, Google user data is disclosed only when the law requires it, and — in a merger, acquisition or sale of Binatomy — only with the user’s explicit prior consent. It is never sold, rented or brokered, never given to an advertising network or an analytics product, and never used to assess anyone’s creditworthiness.

No human at Binatomy reads a user’s calendar data, except with that user’s explicit consent (for instance when they ask for support and authorise access to their account), where necessary for security investigations, to comply with a legal obligation, or for narrowly scoped internal operations on data that has been aggregated or anonymised.

AI and machine learning

Availability and booking sync — the two things the integration exists for — never involve a model: they are ordinary code reading and writing calendar entries. Google Calendar data reaches a language model on one path only, and only because the user asked a question on it.

• The provider is Mistral AI SAS, a French company, processing in the European Union. Bink calls its API directly: there is no aggregator, gateway, router or model hub in between, and no other model provider receives Google user data.
• It is a processor, not a partner. Mistral acts on Binatomy’s instructions, on the terms of its commercial agreement.
• Training is switched off, and that is a verifiable setting. Binatomy is on a paid, pay-as-you-go plan, and in the provider’s API privacy settings the option that allows API calls to be used to train its models is disabled for the entire organisation. Labs models are not enabled and are kept that way: with those enabled the provider may use the data for training even with that option off, on any plan.
• Nothing is retained for training on our side. Bink does not store the events read for an answer, does not build a dataset from them, and does not develop, improve or train any model — generalized or otherwise — on Google user data, whether raw, aggregated, anonymised or derived.
• A third-party assistant only ever arrives with the user. A user may connect an assistant of their own (for example Claude or ChatGPT) to their Bink account with a key or an OAuth authorization they create themselves. That assistant can then call the same functions on that user’s own account, and the calendar data reaches the provider the user chose, at the user’s initiative and under the user’s own agreement with them — Binatomy transports the request and has no other role in it. Nothing is connected by default, Binatomy sends no Google user data to any such provider on its own initiative, and the key or authorization is revocable from Bink settings at any time.

Affirmative statement, in the wording required for Workspace APIs:

The use of raw or derived user data received from Workspace APIs will adhere to the Google User Data Policy, including the Limited Use requirements.

Google API Services User Data Policy

Bink’s use of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements, and to the Google Workspace API User Data and Developer Policy.

Calendar data is used only to provide the booking feature to the user who granted access. It is never sold or transferred, never used for advertising or for training AI models, and is not shared with third parties except as processors listed in our privacy policy.

The use of raw or derived user data received from Workspace APIs will adhere to the Google User Data Policy, including the Limited Use requirements.