Privacy Policy

Assistant chat

Your message (up to 4,000 characters), up to the last 40 messages of that conversation, and up to six short sections (each up to 2,000 characters) taken from the uploaded documents that match your question, at most 16,000 characters of document text in total. Documents are split into sections once, on our server; only the sections that match are sent, never the whole file. The document types the assistant can read are plain text and Markdown files, Word documents and PDFs. For a Word document or a PDF, the file is opened on our server and only the text is sent, never the file itself. A PDF that contains no text at all (a contract someone photographed or scanned) has no text to extract, so nothing from inside it is ever sent. If such a file matches your question by its name, the assistant is told that the file exists and that nothing could be read out of it, so that it can say so instead of answering as though you had never uploaded it. What it is told in that case is the file name and the folder name, and nothing else. When you upload one of the readable kinds, the text inside it is extracted once, on our server, and kept as a plain-text copy in your workspace, split into sections, so that a question can find a document by what it says and not only by what it is called. Documents that were already in your library before this feature existed are read once in the same way, in the background, so that an older file can be found by its contents too. That copy stays in your workspace under the same access rules as the file itself and is deleted with it. Extracting it is not itself a transmission: the file is opened on our server. What is sent to a provider, and when, is the excerpts described above and the fingerprints described in the next paragraph, and nothing else. The assistant reads no other file type: an image, a spreadsheet or anything else in your library is never opened and never sent by it, whatever its name suggests. (The caption generator is the one place an image itself travels, and only when you attach it there; see below.) Document selection runs on your question alone, before the model has said anything: your question is matched against the names of your documents, the names of the folders they sit in, and the stored text copy described above, so a document can be picked because of what is written inside it and not only because of what it is called. If the assistant uses one of its tools, what that tool read from your workspace (shows, deals, contract data) goes back to the model as the tool's result. We tell the model in the prompt that document text is untrusted content and that instructions inside it are not to be followed. Every turn, every tool call and every tool result is stored in your workspace.

Fingerprints of the sections. To let a question find a section by its meaning and not only by the exact words in it, each section is once turned into a numerical fingerprint (an embedding). For that the section text is sent, once, to the same provider your workspace uses for the assistant: Mistral on its EU endpoint for platform AI, or OpenAI if you saved an OpenAI key. This happens when you upload or save a file, and once in the background for every document that was already in your library before this feature existed. With an Anthropic key no fingerprints are made and the assistant searches by words only. Your question is turned into a fingerprint the same way when you ask. The fingerprints are numbers, not text; they are stored in your workspace next to the plain-text copy, are never exported, and are deleted with the document. This happens only while the assistant is switched on for your workspace; it never happens for a workspace whose AI is off or whose assistant is off. What the provider keeps of such a request is governed by its own terms, listed in Section 9.

What the assistant can read from your workspace. The assistant does not have the run of your data. It reads a fixed table of areas, and within each area a fixed list of fields, listed below in the names the code itself uses. A field that is not on this list cannot reach the model through the assistant, whatever else is stored on the same record. Every area is also gated: you are offered an area only if your own account may open that part of the app, so the assistant cannot tell you anything the interface would keep from you.

Two limits hold for all of them. One reading of an area returns at most 20 rows. And a field nobody filled in comes back as null rather than being dropped, so the model can tell an empty field from a field that does not exist, and says so instead of inventing a value.

• contracts (managers only): contractType, status, title, parties, paymentDirection, paymentBasis, paymentAmount, paymentPercentage, paymentPercentageOf, paymentCurrency, paymentSchedule, paymentDeadline, renewalDeadline, effectiveDate, endDate, responsiblePerson, cancellationTerms, note.
• shows (the tour team): id, date, type, title, venue, city, country, address, status, capacity, loadIn, soundcheck, dinner, doors, stageTime, curfew, advanceState, parkingNote, notes. Fees and deal terms are deliberately not in this list; they have their own manager-only tool.
• tours (the tour team): id, name, status, startDate, endDate. The budget on a tour is money and is not in this list.
• tour-legs (the tour team): id, tourId, name, startDate, endDate.
• tasks (the tour team): title, status, due, priority, area. Archived tasks are left out. One narrower thing travels further, and it is the only one: when somebody hands a task to a member of your team, the activity log records that it happened, the task's title, and the display name of the person it went to, which everyone in your workspace can read. What the task says, when it is due, which category it carries and what it is linked to are never in that record, and neither is anybody's email address.
• contacts (the tour team): name, role, roles, org, phone, email, emails, phones, note. That is phone numbers and email addresses (a person may have several, and all of them are in this list), not one of each, and a person may carry several roles (promoter and owner, booker and marketing), all of which are in this list too. This is personal data about other people, so this area reaches exactly the accounts that see the contact book itself. One narrower thing travels further, and it is the only one: when somebody adds, changes, imports or deletes a contact, the activity log records that it happened and the person's name, which everyone in your workspace can read. Their phone numbers, email addresses, organisation and note are never in that record. The same is true of an organisation: adding, changing or deleting one records its name in that log, and nothing else about it.
• organisations (the tour team): name, kind, website, emails, phones, note. This is the register your contacts are grouped by: a venue, a promoter, a label, a broadcaster or an agency. An organisation is not a person, so these are not somebody's personal details in the way the line above holds them. The email addresses and phone numbers here are an office's, they belong to real people at the other end, and they are read by exactly the accounts that see the contact book itself and by nobody else. Which place a venue sits at is deliberately not in this list, and neither is anything about the people who work there: they are in the contact book area above, each with their own addresses and their own roles.
• travel (the tour team): date, mode, from, to, departTime, arriveTime, arriveDate, distanceKm, flightNumber, note.
• stays (the tour team): date, name, city, checkIn, checkOut, nights, rooms, address, status, sleepArrangement, costAmount, costCurrency. What a stay costs is in the list because it is on that screen for the same people.
• files (anyone who can open your files): name, folder, contentType, size, uploadedAt. This is the listing only. The contents of a file reach the model through the document excerpts described at the top of this box, never through this area.
• merch-products (the merch team): id, name, productCategory, active. The catalogue entry only. What you wrote in the notes field of a product is not in this list.
• merch-variants (the merch team): id, productId, variantType, size, color, prices, unitCost, unitCostCurrency, reorderAt, active. Prices and the production cost are in the list because they are on the same screen for the same people. The supplier code (sku) is not.
• merch-transfers (the merch team): variantId, qty, from, to, date. Stock movements. The note on a movement is not in this list.
• merch-settlements (the merch team): id, tourId, showId, showLabel, showDate, showCountry, currency, lines, payments, venueCut, attendance, status. A night's takings. lines is the counted stock of that night, one entry per variant, each with the four counts and the price that was frozen on the night. The note on a night is not in this list.
• incomes (managers only): category, amount, currency, date, received, receivedDate, source, tourLabel, tourDeletedAt, showLabel, showDate. Money with no other source in the app: a grant, a sponsorship, a session, a licence, a royalty statement. Show fees and merch takings are not rows here. received is in the list because it is what the figure means: an amount that has not arrived is expected money, and the assistant is told in words never to report it as money in hand. The note on an income and the documents attached to it are not in this list.
• expenses (managers only): category, amount, currency, date, payee, tourLabel, tourDeletedAt, showLabel, showDate. Who was paid is in the list because what a payment was for has no answer without it. The note on an expense and the receipts attached to it are not.
• songs (the tour team): id, title, key, tempo, durationSec, album, year, inDefaultSet, defaultPosition. Your song library. inDefaultSet is in the list because without it the assistant would read the whole catalogue as one night's set. There is no free-text field on a song, so there is nothing here to withhold.
• setlists (the tour team): id, name, shareViews, shareLastViewedAt. The setlist documents by name, plus how often the public link was opened and the day it was last opened. The link's own address (shareId) is not in this list: anybody holding that address can open the setlist, so it is the share itself rather than a fact about it.
• setlist-entries (the tour team): setlistId, position, songId, special. The lines of a setlist in their running order. A line is either one of your library songs or an ad-hoc song that is not in the library, and special is that ad-hoc song: its title, what kind of song it is, and its key, tempo and length. The note you wrote on such a song is removed before the line leaves your workspace.
• riders (the tour team): id, name, shareViews, shareLastViewedAt. The rider documents by name, with the same two share counts, and the link address withheld for the same reason as a setlist's.
• rider-items (the tour team): riderId, category, item, qty, position. What one show's rider asks for. The note on a line is not in this list.
• rider-template (the tour team): category, item, qty, position. Your Default Rider, the master list a new show's rider starts from. The note on a line is not in this list.
• social-accounts (the social team): id, platform, handle, status. Which channels this workspace reads numbers from, and whether each connection is live. The stored key or token behind a connection is not in this list and is never readable by the assistant, and neither is the channel id, the last error a platform sent back, or a subscriber figure you typed in yourself.
• social-metrics (the social team): socialAccountId, date, followers, views, likes, engagementRate, reach, newFollowers, videoCount, estimatedMinutesWatched, followersPrecision, followersDerived, source. One row per channel per day, the same numbers the social pages draw. The eleventh and twelfth fields say how sharp a follower count is and whether it was measured or reconstructed, and they are in the list for the same reason received is in the income list: without them a rounded or computed number reads as a measurement. The last one says where a row came from, including whether it is seeded sample data rather than a real figure.
• instagram-posts (the social team): timestamp, mediaType, mediaProductType, permalink, caption, likes, comments, views, reach, saves, shares, totalInteractions. Your own posts with their own numbers. The caption is the first part of the text only. The picture and thumbnail addresses are not in this list: they are signed links that expire, so they are a credential rather than a fact about the post.
• youtube-videos (the social team): videoId, publishedAt, title, durationSeconds, views, likes, comments, liveBroadcastContent. Your uploads with their lifetime figures. A video's description and its day-by-day view history are not in this list. Videos on other channels that your workspace chose to track are stored in this same area, and the assistant is not offered them: it reads your own uploads only.
• youtube-audience (the social team): dimension, date, windowStart, windowEnd, rowCount, rows. Who watched your channel over a 28 day window, where from, on what, and after searching for what. There is no personal data in these reports: YouTube publishes them as shares and totals precisely because they identify nobody, and the age and gender shares cover signed-in viewers only. The two window fields are in the list because a share without its window is not a measurement. The rows are not handed over as stored: YouTube's report tables are kept exactly as Google sent them, so each row is rebuilt from a fixed list of columns for that report before it leaves, and a long report is put in order of size and cut to its largest fifteen entries. The age and gender report is the one that is never cut, because those shares only mean anything together. A column this app has not named cannot travel, whoever added it.
• content-goals (the content team): id, name, tagline, sortOrder. The groups your content library is sorted into, with the one line under each name. Archived groups are left out. The longer description of a group is not in this list.
• content-series (the content team): id, categoryId, name, subtitle, coreStack, purpose, primaryPlatforms, suggestedFrequency, energy, editEffort, exampleHooks, occasions, origin. Your repeatable formats: what each one is for, which channels it is planned for, how often it is meant to go out, what filming and cutting one episode takes, and the example hooks that come with it. The last field says whether a series came with the library or you created it yourself, so the assistant cannot present a library default as your own invention. Your own notes on a series are not in this list and the assistant has no way to read them. Neither is the long reference text on a format.
• content-hook-groups (the content team): id, name, subtitle, sortOrder. The sections your hook library is divided into, each with the framing question printed under it. Archived groups are left out.
• content-hooks (the content team): questionCategoryId, text, sortOrder. The hooks themselves, in their group and in their order. These are starting points to film against, not anything you have said. Archived hooks are left out.
• content-shoots (the content team): id, date, label. The days you filmed on, which is what several calendar entries planned for one afternoon have in common. The free-text notes on a filming day are not in this list.
• content-calendar (the content team): id, scheduledFor, platform, status, shootId, seriesId, caption, filmedAt, editedAt, postedAt, oneOff, showLabel, showDate. Your planned and published pieces. The caption is the text of the piece itself, which is what tells one entry from another. The fourth field is the stage a piece has reached, and it is in the list for the same reason received is in the income list: without it a plan reads as something you published. The last two are filled in only when a show a piece was planned for has been deleted, so they are a frozen name rather than a live link. Which show a piece belongs to is otherwise not readable through the assistant at all. The free-text notes on an entry are not in this list.
• content-my-strategy (the content team): id, name, status, platforms, rhythm, endDate, createdVia, episodes, createdAt, updatedAt. Your own series on the My Strategy screen: the channels each one runs on, how often it is meant to go out, whether it is running, and the episodes you planned for it. An episode carries its number, its hook, its topic, the days you meant to film, edit and post it, and the stage it has reached. The third field is in the list for the same reason received is in the income list: a series you started and left is not a series you are running. The notes you wrote on a series, and on any single episode, are not in this list and the assistant has no way to read them. The episode note is a special case worth saying plainly: it sits inside the episode rather than beside it, so it is removed before the episode is handed over, not merely left off this list. Planning you made before the current version of that screen is not readable here at all.
• content-drafts (the content team): channel, format, status, outputType, targetSeconds, seriesId, text, incomplete, createdAt. The captions, outlines and talking scripts this app generated for you and you kept, with the writing itself. The fourth field says which of those three a row is, and it is in the list because nothing else on the row does. The eighth says the provider cut the generation off, so a shortened text can never be handed over as a finished one. A draft you discarded is left out of this area entirely. What you typed as the description of the post, and the context you handed over for one generation, are not in this list. Neither is the picture you attached.
• places (the tour team): placeType, name, city, country, address, capacity, parkingNote. The reusable places your workspace keeps: venues, hotels, airports, stations, rehearsal rooms. The first field is what tells a room from a bed and it is in the list because nothing else on the record does. Capacity is how many people the place holds, never how many came. The free-text notes on a place are not in this list, and neither are its map coordinates.
• route-stops (the tour team): tourId, date, city, country, place, sortOrder. The dated points on a tour's route that are not shows: where the tour is on a day when there is no concert. The cached driving distances and times between two stops are not in this list, because the app itself re-checks them before drawing them and a copy handed to the assistant could be out of date. Your own note on a stop is not in this list either.
• guest-list (the tour team): name, passType, status, passes, photoPasses, showId, tourId, excludedShowIds, createdAt. Who is on the door lists, which pass they hold, and whether the entry is still a request or has been approved. Your guests' email addresses and phone numbers, anything recorded about what they need in order to get in and get around, and the notes about them are not in this list. One rule here is about whole entries rather than fields: an entry marked visible to managers only is removed from the answer before it leaves the server for anybody who is not a manager, exactly as it is on the screen itself.
• memberships (managers only): role, caps, createdAt. One row per person who has access to this workspace, saying what that person may do and when the access was given. There are no names and no email addresses in this area at all. The account behind a row is identified by an internal id, and that id is not in the list, so the assistant can say how many people have access and at what level and cannot say who they are.
• newsletters (the content team): title, occasion, status, scheduledFor, sentAt, createdAt. This is the listing of your newsletters and never their text. What a newsletter says is not in this list and the assistant has no way to read it. Neither are the notes you typed into the form it was generated from. The third field is in the list for the same reason received is in the income list: a draft is not a letter that went out. This app has no sending in it at all, so sent is a mark you set by hand after sending the letter from somewhere else, and the assistant is told in words never to report a newsletter as delivered or to say who received it.
• voice-samples (the content team): kind, platform, occasion, title. The past pieces of your own writing that you saved so the AI features can imitate your voice, as a shelf: how many there are, what kind each one is and where it was published. The text of a sample is not in this list and the assistant has no way to read it. That is the strictest omission on this page and it is deliberate: as the newsletter box below says, these are real past messages, so one can carry the name of the person it was once sent to. Where an imported sample came from, including the account handle it was pulled out of, is not in this list either.
• press-kits (the content team): label, bioShort, facts, showUpcomingShows, showSocialStats, viewCount, lastViewedAt, updatedAt. Your press kit: its internal name, the short biography and highlight lines on it, whether its two live sections are switched on, and how often the public page has been opened. Nothing is recorded about who opened it, so the assistant can say how many times and when, never by whom. Whether the press kit is public, and its public web address, are not in this list. The address is withheld because anybody holding it can open the page, so it is the share itself rather than a fact about it. The long biography, the press quotes, the latest-release block, the contact list on the kit and the photos, files, videos and links attached to it are not in this list either, and the contact list matters most of those: it can hold an email address and a phone number typed straight onto the kit.
• external-listings (the tour team): provider, syncState, lastSyncedAt, firstSeenAt, showId, snapshot. What this app knows about your shows on Bandsintown: whether each one is linked, has drifted apart from the local show, vanished from the service, or was deliberately set aside. snapshot is what the service said about the event at the last scan (its date, venue, city, country, start time and ticket link) and it is never copied onto your show; it is in the list together with the date of that scan, because an upstream reading without its date reads as the current state of a show. The service's own id for the event is not in this list.
• tour-calendar (the tour team): tourId, date, title, startTime, endTime, kind. The dated entries that are not concerts: press, radio and TV, interviews, shoots, promo, rehearsals, meetings, travel days, days off and admin blocks. An entry does not have to belong to a tour. What you wrote in the notes field of an entry is not in this list.
• setlist-rider-versions (the tour team): showId, kind, version, label, createdAt. This says which saved versions of a setlist or a rider exist, and never what is in one. The songs and the rider lines frozen inside a saved version are not in this list, and neither is the name of the person who saved it.
• file-folders (anyone who can open your files): path, createdAt. The folders somebody created on purpose, so that an empty folder can be seen at all. Nothing about what is in them; the files area above is the listing.
• activity-log (everyone who can use the assistant): at, kind, label, detail, actorName, visibility. Your workspace's own record of what people changed and when, the same record the Activity log page under Settings shows you. This is the one area in this table whose rows are filtered by who is asking. Entries the workspace treats as money, such as a changed fee, a changed deal or a changed price, are readable only by a manager, exactly as on that page, and the assistant is handed the filtered rows rather than filtering them itself. The email address and the account id of the person who made a change are not in this list; the display name they had at the time is.
• workspace (everyone who can use the assistant): name, currency, distanceUnit. Three fields out of the roughly twenty-five on that record, which is what an allow-list is for.

Everything else the app stores is outside that table and the assistant has no way to read it, and there are three reasons a table is outside it. Some of it is personal rather than the workspace's: your own day notes belong to the person who wrote them, and there is no version of them the assistant reads. Some of it is an old store that a newer one replaced, kept only so nothing is lost, which the assistant would otherwise report as current. And some of it never gets an area at all, and the plainest cases are worth naming: stored keys and tokens, invitations, other people's conversations with the assistant, your audience's survey answers, and what individual people on the platform voted for or last read.

Newsletter draft

Artist name, the occasion, your own notes, the call to action, your links, and, if a tour is linked, that tour's name with its show dates, cities and venues. Plus your tone and sign-off and up to three style samples from your voice corpus. Those samples are real past messages, so they can carry the name of the person they were once sent to.

Content coach (Cue)

Artist name, the series format or the series you opened it on, and the conversation turns. On a series format in your Library, or on one of your own series, it also sends a capped list of your own songs and next shows. Your private artist notes are not read, only what you type into the visible field.

Cue also has a page of his own, under Content. Its guided door, the one that asks you three short questions, sends nothing to any provider: its questions and its suggestions are a filter over the formats in your own library, and it works with no AI key at all. What that conversation produces is stored in your workspace: the series it sets up, its episodes with the hooks and notes you wrote, the entries it puts on your calendar, and a setup you left unfinished, which is kept as a draft series so you can pick it up later. The conversation itself is not stored. Leaving the page ends it.

That conversation, and the one-off mask on My Strategy, can also plan single clips with no series behind them, on their own or as one batch across several songs. Those are stored as ordinary calendar entries with the hook and the note you wrote, the days you picked, and the song title where you named one; each is marked as a one-off, which is what lets it appear in the One-offs list on My Strategy. Nothing about them is sent anywhere.

The second door on that page, where you describe what is on your plate in your own words, is the one part of Cue that does call an AI provider, and it needs your AI key. It sends your artist name, what you typed, the formats in your own library with their purpose, when they are the right tool, what they cost in time and their starter hooks, and a capped list of your song titles and next shows, so Cue can put a title or a city into a hook that has a gap in it. It does not send your plan, your calendar, your drafts or your private notes, and it can only point you at formats you already have. Neither what you type there nor the answer is stored; leaving the page ends it.

From that answer Cue can also offer to set the idea up as a series of your own or as a single clip, and the name and the angles he suggests come out of the same answer, so nothing further is sent anywhere for it. Choosing either one opens a form with those words already in it, and nothing is stored until you save that form. If you do, the series or the clip is stored as described above, and the sentence you typed into the box is kept with it as a note on the series, where you can read it on its card in My Strategy.

A third door on that page checks the plan you already have: it lists the series with episodes that are past their day, and it can pause one, pick it back up, move a stalled run forward, or work its days out again for a different rhythm. Those four things call no AI provider and need no key. They send nothing anywhere and read only your own series and their days. They store nothing new: they change the episodes and the calendar entries you already have, and they tell you exactly what they moved. And an episode that had no day and gets one through the new rhythm is put on the calendar like any other episode with a day.

That third door also has a review, and it is the one part of it that does call an AI provider and needs your AI key. Pressing one of its three questions, or typing your own into its field, sends your artist name, the one series you have open with its name, platforms, rhythm, end date and status, and its episodes with their number, hook, topic, status and film, edit and post days, at most 24 of them. It does not send the notes you wrote on those episodes, any of your other series, your library, your calendar or your drafts. Nothing from it is stored, and it changes nothing in your plan: it answers in words, and the four buttons above it are what move anything.

Caption generator

Your description of the post, the series format's purpose, the hook you chose, anything you put in the context box, and style samples from your corpus filtered to that platform. Opening this form from an episode of My Strategy fills in the hook and the context box for you; both are on screen before anything is sent, and you can change or clear either. If you attach an image, the image itself is sent to the provider as raw bytes along with the text.

Filming scripts (outline and talking script)

The Create tab can also plan a shoot: first an outline in seconds, then, if you ask for it, the words you say to the camera. Both send your artist name, the name of the series the episode belongs to and the purpose of the series format it is based on, the hook and the song or subject of the episode, the platform and the target length in seconds, whatever you wrote in the visible field about how and where you are filming, and the tone from your voice profile.

The talking script sends two things more. It sends the outline exactly as it stands on your screen at that moment, including any edit you made to it, and up to three of your own past posts on the chosen platform as style examples, each cut to 600 characters (the title and the text). Those samples are real past posts, so they can carry real names, dates and places. The outline stage sends no past posts at all.

Opening this from an episode of My Strategy ("Plan filming") fills in the hook, the song or subject, the platform and the target length for you, and puts the note you wrote on that episode into the visible field about how and where you are filming. All of it is on screen before anything is sent, and you can change or clear any of it.

Neither stage sends your private notes, the notes on your episodes, your calendar, your other series or your other drafts. What comes back is stored as a draft in your workspace, where you can edit it or delete it.

Social AI read

Artist name and handle, per-channel metric summaries, spikes and milestones, the dates of shows and newsletter sends, and labels for your Instagram posts. No raw fan data. It runs when you press Refresh; there is a per-artist setting that can make it run automatically when the page opens, and its default is manual.

Survey AI

This runs in two separate calls, and the split is the privacy boundary.

The first call reads the form, not the answers: question ids, titles, types and the answer options you wrote yourself. By design it contains no fan email addresses, no free text, no locations, nothing per person and no counts.

The second call reads your audience's free-text answers and sends them to the provider. This is the one place where a fan's own words leave this server. Email questions can never be part of it. Any question the first call flagged as containing personal data is excluded too, unless a human explicitly turns that question back on. Choice, numeric, ranking and location answers are never sent.

Instagram and Facebook (Meta)

There are three ways to connect, and each asks only for what it needs:

• An Instagram professional account through Instagram Login: instagram_business_basic and instagram_business_manage_insights.
• An Instagram account reached through its linked Facebook Page: instagram_basic, instagram_manage_insights, pages_show_list, pages_read_engagement and read_insights.
• A Facebook Page on its own, with no Instagram involved: pages_show_list, pages_read_engagement and read_insights. The two Instagram permissions are deliberately dropped on this path.

What we read: your account and profile information, follower counts, reach and engagement, and your posts with their captions, links, timestamps, like and comment counts and per-post insights. Our use of this data is strictly read-only. We do not create posts, send or read direct messages, or write comments. Tokens are encrypted at rest using AES-256-GCM. Information obtained through the Instagram API is handled in line with Meta's Platform Terms and Developer Policies.

YouTube (Google) · YouTube API Services

Back of Node uses YouTube API Services. By using the YouTube features of this app you agree to the YouTube Terms of Service. Google's own handling of your data is described in the Google Privacy Policy. Our use of information received from YouTube API Services complies with the Google API Services User Data Policy, including its Limited Use requirements.

There are two separate paths, and only the first involves a Google login:

• Your connected channel. We request exactly one OAuth scope, https://www.googleapis.com/auth/yt-analytics.readonly, and no others. It gives us your channel's own analytics: daily views and watch time, and rolling 28-day audience snapshots, which are aggregated shares (for example age bands or countries) and never data about an individual viewer. We deliberately do not request youtube.readonly: no access to your video library, no upload, no edit, no comment, no reading of anyone's subscriptions.
• Public channel statistics. Public subscriber and view counts for a channel id, fetched with a YouTube Data API key. No Google login, no personal Google data.
• Tracked videos on other channels. Public view, like and comment counts and the channel's public name for videos you add by link, fetched with a YouTube Data API key. No Google login. Removing a video deletes its stored history.

Revoking access. You can disconnect YouTube inside Back of Node at any time; when you do, we also call Google's token revocation endpoint. Independently of us, you can revoke Back of Node's access to your Google account at any time through the Google security settings page, https://myaccount.google.com/permissions.

Separately from any connection: public press-kit pages load YouTube video thumbnails from i.ytimg.com in the visitor's browser (Sections 2 and 7).

TikTok

We request three read scopes and no others: user.info.basic, user.info.profile and user.info.stats. We deliberately do not request video.list.

Once a day we read exactly seven fields about the connected account and nothing else: open_id, display_name, username, profile_deep_link, follower_count, likes_count and video_count. Nothing per video, nothing about your viewers, no content, no messages. TikTok is never written to.

Tokens are encrypted at rest with AES-256-GCM. TikTok issues an access token valid for about 24 hours and a refresh token valid for up to 365 days; while you stay connected the access token is refreshed automatically. When you disconnect inside Back of Node we call TikTok's token revocation endpoint and delete the stored token. You can also remove Back of Node on TikTok, under Settings and privacy → Security and permissions → Manage app permissions.

Bandsintown

The artist name you configure travels in the request URL together with our application id, and public event data comes back. There is no login and we receive no personal Bandsintown account data.

Tally (surveys)

If you connect a Tally form, we read the form, its questions and up to the latest 2,000 responses with your Tally API key, live, each time you open the survey page. Those responses come from your audience, not from you, and can contain their email addresses, locations and free text.

Two things we do because of that. Every one of those requests is marked no-store, so the framework never writes a response body to its own disk cache, and the survey page is rendered fresh on each request for the same reason. And the Tally key is kept server-side only and encrypted at rest, because a Tally API key carries the rights of your whole Tally account and has no narrower scope available.

What of this can reach an AI provider, and what can never, is in Section 4.