Privacy policy

Cached GitHub reads

What we hold

Short-lived copies of the public Discussions, Issues and Releases a Board shows. They expire on their own and are the same for every visitor: nothing in them records who was looking.

Why we hold it

Anonymous visitors all read GitHub through one shared token with one rate limit. Without a cache, one popular Board would use it up for everyone.

Board owners

What we hold

Which GitHub accounts have shown they can write to a Board's repository, and when we last checked.

Why we hold it

We hand out no permissions of our own. Write access on GitHub is the only thing that makes someone a Board's owner, so we have to remember who passed the check.

Boards taken down

What we hold

The name of every repository whose owner took its unclaimed Board down, with who did it and when.

Why we hold it

A takedown has to last. Without this list, the next visitor to type the URL would bring the Board back. Only someone with write access to the repository can reopen it, by claiming it.

Subscriptions

What we hold

One row per subscription with our payment processor: the account it belongs to, the plan, its status, when the current period ends and the processor's subscription id. We build it from the processor's signed webhook events and do not keep the events. For each private Board a subscription pays for, we also hold the repository name, the subscription id, and which account attached it and when.

Why we hold it

Private Boards are a paid feature, so showing one means knowing whether its payment is current.

Support conversations

What we hold

For each Support Inbox conversation on a private Board: the visitor's email address, the repository and Issue number the conversation lives in, a random conversation id, whether mail to that address still arrives (or bounced, or was marked as spam), and when the conversation started and when we last emailed about it. The messages themselves are the Issue in the repository. The email address is never written there.

Why we hold it

People who write to a Support Inbox have no GitHub account, so email is the only way to tell them the Board's owner replied, and keeping the address out of the Issue is the point. To be forgotten, reply in your conversation and ask: the Board's owner deletes the row, no more mail goes to the address, and the Issue stays, signed with the conversation id only. The Board's owner can also export the addresses we hold for their Board, with each conversation's Issue link and whether mail to it still arrives, so they keep them if they leave Gitback; once exported, the owner is responsible for that copy.

FAQ question limit

What we hold

For each IP address that asked a Board's FAQ a question in the last minute: a one-way hash of the address, when that minute started and how many questions it asked. Never the address itself and never the question. Each row is deleted when its minute ends. For each Board asked a question this UTC day, and for all Boards together, how many questions were passed to the AI model that day, whether or not they were answered, with no address, question or account. A day's counts are deleted when the next day's first question arrives.

Why we hold it

Every answer is a paid call to an AI model, so one visitor asking nonstop could use up the answers every Board shares. The limit is ten questions a minute per address, 200 a day per Board and 1,000 a day across all Boards, counted across all our servers.

Your GitHub sign-in token

What we hold

The GitHub token you get when you sign in, kept encrypted in a cookie only our server can read, for as long as you stay signed in. On a Board with its own domain, once you confirm signing in there, it is also kept encrypted in a cookie on that domain for up to 8 hours; it travels there once, inside an encrypted link that expires within 60 seconds. If you connect an AI tool to Gitback over MCP and click Allow, it is also encrypted into the codes and tokens that tool keeps in its own settings: an access token that lasts 1 hour and a refresh token that lasts 30 days. We store it nowhere else: no database row, no account record, and we remove it from our sign-in provider's own cookie before that cookie is written. Signing out deletes the cookie.

Why we hold it

On a public repository's Board, and on any Board whose repository your sign-in can write to, everything you post through Gitback is posted by your own GitHub account, so our server needs your token after you sign in. It is the only credential here that can write to your repositories. On a private repository's Board you cannot write to, the Gitback App posts for you and names you, and your token only tells us who you are.

Your Coduo account link

What we hold

The link between your customer record with our payment processor and your sign-in account: its account id, stored on that customer record.

Why we hold it

Gitback's billing runs on Coduo, the shared account system behind our products. Payments from a customer record without this link are ignored, so the link is what makes your payment count for you.

The account itself is your sign-in account, listed below, created when you first sign in. Gitback only adds the link to your customer record with the payment processor and reads your account back.

Product membership

What we hold

The record that says your Coduo account uses Gitback.

Why we hold it

One Coduo account works across every Coduo product, and membership is how Coduo ties yours to Gitback.

Coduo writes and keeps these records. Gitback neither writes nor reads them.

Your answer on repository writes

What we hold

Whether the Board's owner said yes or no to Gitback writing files and labels in their repository, or later withdrew a yes, and when.

Why we hold it

Several parts of a Board work differently depending on the answer, so we keep it whichever way it went.

Your browser's own storage

What we hold

Nothing on our side. These are things Gitback saves in your own browser; they never leave it and we never see them. There are five. Feedback you typed before signing in: saved in session storage when Submit sends you to GitHub, put back in the box when you return, then deleted. A vote, comment or post you started in an embedded widget before signing in: saved the same way, including the text of a comment, and deleted as soon as you come back signed in: the vote is then cast, and the comment is put back in its reply box rather than posted. Both are gone when you close the tab, whether or not you came back. Your light or dark mode choice: saved in local storage so the page does not flash the wrong one next time. When you last looked at each Roadmap column: one timestamp per column, so the Roadmap can show what is new since. Your browser works that out from cards it already has, without asking us. And if you own a Board and are editing its Theme: your unsaved changes, so they are still there when you come back. They are cleared once the Theme matches the live one again, by undoing your edits or by publishing; saving a draft keeps them. Next to them sit the preview stylesheet, the pull request a saved draft opened, the theme you last published, the theme your draft started from (so a draft can move onto a theme published since), and what Auto-detect found in your repository (so it is read once, not every time you open the Theme), so the Theme section and the Board can use each one without asking us. Everything in local storage stays until it is replaced or you clear your browser's data. The cookies Gitback sets are listed separately, under Cookies.

Why we hold it

Each of these makes the page work better without sending anything to us. The first matters most: signing in takes you away from the Board, and without it the message you typed would be lost.

Board visibility

What we hold

For every Board, public or private repository: whether its Client has published or unpublished it, the optional link the unpublished screen offers, and which Sections were live when it was last published.

Why we hold it

A Board shows Visitors only as much as its Client chose to share, and an unpublished Board can send them elsewhere.

Custom domains

What we hold

Which domain shows which Board: one domain per Board, the repository it points to, and when it was added.

Why we hold it

A visit to a Board on its own domain tells us only the domain name. Without this record we could not tell which Board to show.

AI tool connections

What we hold

For each GitHub account that has connected an AI tool over MCP: a counter for disconnecting, plus the ids (never the values) of codes and tokens already used. Each id is dropped once it would have expired anyway, after 30 days at most.

Why we hold it

The tokens an AI tool holds are encrypted envelopes we keep no copy of, so disconnecting has nothing to delete. Raising the counter cancels all of them at once, and the used ids make sure each code works only once.

The waitlist

What we hold

For each GitHub account that joined the waitlist on gitback.us: its GitHub user id and login, the email address GitHub gave us (if it gave one), the plan you joined from (if you joined from a pricing card), and when you joined. Joining again changes nothing.

Why we hold it

So we can tell you when Gitback opens, and know which plan you were interested in.

Product analytics and error reports

What we hold

Events held by our analytics provider in the EU about how Gitback is used: which page or action, which Board and whether its repository is private, what kind of viewer did it (anonymous, End User, Triager, Client), and where the visit came from (UTM campaign tags and the referring site). If you are signed in, your GitHub user id, login and sign-in tier, and the campaign you first arrived from. Error reports from your browser and from our servers, with a stack trace. No IP address, no location, no text you write (feedback, comments, questions, emails) and no session recording.

Why we hold it

To find and fix errors, and to see which pages, Boards and campaigns people use.

Our analytics provider, in the EU, holds these for us. Its script runs in your browser and sends through Gitback's own domain. An anonymous visit sets no analytics cookie and stores nothing in your browser. When you are signed in, Gitback's existing signed-in cookie carries your GitHub user id so your events join up.

Votes on a private repository's Board

What we hold

For each Vote cast on a private repository's Board by someone whose sign-in cannot write to it: your GitHub user id and login, the item you voted on, and when you voted. One row per account per item. We keep it until you take the Vote back or the Board is deleted. The item on GitHub shows only the total, never who voted.

Why we hold it

People who cannot see a private repository on GitHub cannot react to its items, and the Gitback App can add only one reaction per item. So we keep one row per voter to count each person once.

Your sign-in account

What we hold

When you first sign in with GitHub, our sign-in provider creates an account for you: a random account id, the primary verified email address on your GitHub account, your GitHub user id, login, name and avatar link as GitHub returns them, and when you signed up and last signed in. It also logs each sign-in, with the IP address it came from. Your sign-in session is kept in a cookie (listed under Cookies). It never holds your GitHub token. We keep the account until you ask us to delete it.

Why we hold it

Signing in is how we know who is voting, posting, claiming a Board or paying. The account id is what your subscription and Board ownership hang off, and the email address is the one our payment processor is given when you pay.

Roadmap columns

What we hold

Which roadmap column each Issue sits in.

Why we hold it

Normally this is a label on the Issue in your repository. If you said no to Gitback writing in your repository, we have to keep it ourselves.

Board setup

What we hold

How the Board's feedback categories are set up, and which roadmap items link to which Issues.

Why we hold it

Normally this is a file in your repository. If you said no to Gitback writing in your repository, we have to keep it ourselves.