Privacy Policy

1. Who we are and what this page covers

FlintBeam is an API gateway: you send us a request, we forward it to an AI model provider, and we return the answer. This page describes what we record while doing that, where your prompts go, who else receives data, how long each thing is kept, and what you can do about it. It describes what the service actually does today, not what it might do one day; when the service changes, this page changes with it.

FlintBeam is operated by CONNECT GLOBAL LIMITED, a company registered in England and Wales, number 16714288. For the personal data that describes you as our customer — your account, your keys, your payments, your usage records — we are the controller. For the content of the requests you send through the gateway we act on your instructions and only in transit: we forward it to the provider you named and return the answer, and we do not keep it. You can reach us about any of this at support@flintbeam.com.

2. What we collect and keep

About your account:

• Your email address, and a display name if you set one.
• A hash of your password, never the password itself. We use argon2id, which cannot be reversed back into what you typed.
• The IP address you signed up from, and the IP address and browser description of each session you open. This is what lets you see where your account is signed in and end a session you do not recognise.
• The IP address of each attempt to sign in or register, whether it succeeded or not. Without it, the limits that stop someone guessing at your password could not count anything.
• When you agreed to the terms, and when you agreed to the plan terms, so that the agreement can be shown to have happened.
• Your interface language, so we can write to you in it.
• If you turn on two-factor authentication: the shared secret, encrypted before it is stored, and a hash of each recovery code.
• If you sign in through Google or GitHub: that provider's own identifier for you and the email address on that account.
• Your account settings — for example, what happens when a plan's allowance runs out.
• If you upload a file to the files endpoint (/v1/files): the file itself. Local files expire 30 days after upload; the expiry is returned as expires_at.
• If you join the partner programme: your links and how many times each was followed, per day; which accounts signed up through them (shown to you only by number, never by name or email); the commission earned; and, when you ask for a payout, your full name, your country, a tax number if you give one, and the payout details you choose — a card, a PayPal address or a crypto wallet address.
• If you use the help assistant on our website: your questions, its answers and any pictures you attach, kept for 30 days after the last message.
• To prevent abuse of the welcome bonus and the partner programme, technical identifiers of the device, browser and connection you sign up or sign in from, some of them kept in your browser, and identifiers of the payment methods you use; they are used for those purposes, and kept only as section 10 says. The browser and connection signs are also used to decide whether a saved card may be offered for payment in one click, which happens only from a browser and network already used to sign in to the account. The device, browser and connection identifiers are stored as one-way hashes, not as the values themselves; a payment method's identifier is the payment processor's own reference or, for a payment wallet that has none, a one-way hash of the wallet's email address, kept with the payment records.

About each request through the gateway:

• Which model you asked for and which version answered, how many tokens went in and out (including how many were served from the provider's cache), how long it took, whether it succeeded, which of your keys made it, which provider served it, and what it cost you. That is what your usage page, your bill and our books are built from.
• A request identifier, returned to you in the x-request-id header, so that a question about one request can be answered.
• On supported native /v1/responses models, responses are stored by default for 30 days so you can retrieve or continue them with previous_response_id. Send store: false to avoid storing the response; if you supply a conversation, its input and output items are still saved. Bridged models do not store responses. Conversations you create on /v1/conversations are kept until you delete them, up to 1,000 live conversations per account. Creating a stored file, conversation or response requires a positive spendable balance; when the spendable balance is $0, the request returns HTTP 402. Closing your account erases stored files, conversations and responses. Stored content is encrypted, and only your account can read it.

About money:

• Every credit and debit on your balance, with a description, and every payment: the amount, the currency, the processor's reference and the state of the payment. For crypto payments we store the notification the processor sends us in full. Card numbers, wallet keys and bank details never reach us.

When you write to us, we keep the correspondence for as long as it takes to deal with it and to show afterwards what was agreed.

3. What we do not store

The gateway does not write request or response bodies to its logs. Stored content includes files you upload to the files endpoint (local files expire 30 days after upload; their expiry is returned as expires_at), responses stored by default on supported native /v1/responses models, and conversation items (section 2 and section 10). Send store: false to avoid storing a response; conversation items are still saved when a conversation is supplied. Nothing on our side reads your prompts for any purpose — not to train a model, not to improve the service, not to look at what people ask.

One exception is worth stating rather than leaving for you to find. When a provider refuses or fails a request, we keep the beginning of the error it sent back — at most 400 characters — attached to the record of that failed request, and the same text can appear in our server logs. Providers normally explain themselves rather than quote you, but a refusal on content grounds sometimes repeats the phrase it objected to. That Apart from the stored content described above, that fragment is the only way any part of what you sent can end up in our records.

The help assistant on our website is different, and deliberately so. What you write to it — your messages, its answers and any pictures you attach — is kept so that you can come back to the conversation and so that we can read it if you contact us about it. It is kept for 30 days after the last message and then deleted. To produce an answer, your message and the relevant parts of our documentation are sent to the AI model provider that serves the assistant. None of this applies to requests you send through the API.

4. Where your prompts go

The provider behind the model you chose receives your request in full — the messages, any images, tool definitions and parameters — because it cannot answer without it, and its answer comes back through us. Which provider that is depends on the model you chose, and it can change from one request to the next; the catalogue names the vendor behind each model, and the Model and Provider Terms link each major provider's data policy. The provider processes your request under its own terms, which we cannot change on your behalf.

What that means in practice: the provider may keep your request and the answer for a limited time to monitor for abuse — each provider's own data policy, linked from the Model and Provider Terms, says how long — and may process it in a country other than yours, most often the United States. OpenAI, Anthropic, Google, Microsoft and Amazon each state that data sent through their APIs is not used to train their models; we do not opt into any programme that would change that. Other providers named in the catalogue set their own rules, and we do not speak for them. If what happens to a prompt after it leaves us matters for your work, choose the model with the provider's policy in mind.

Traffic between our service and the providers may pass through network providers over encrypted connections; they see where the traffic goes, not what it says.

5. The chat playground

The chat page on this site is the same gateway with a page in front of it. The conversation you see there is kept in your own browser, not on our server; clearing your browser data clears it. Requests made from it are recorded exactly like requests made with a key, and their content goes to the provider exactly the same way.

6. Why we process personal data

• To provide the service you asked for: your account, your keys, your balance and the record of what each request cost. This is performance of our contract with you; without it there is no service to provide.
• Because the law requires it: payment and accounting records are kept to meet tax, company-law and anti-fraud obligations.
• Because we have a legitimate interest in the service surviving and in keeping it safe for everyone: the sign-in attempt log, the session records, the rate limits and the abuse checks exist to stop password guessing, card testing, fraud and attacks, and they cannot work without recording what happened.
• Because you agreed, where that is the basis — for example when you connect a Google or GitHub account. You can withdraw that consent by disconnecting it.

7. Cookies

One cookie signs you in and keeps you signed in; a short-lived one carries a two-factor challenge between the password step and the code step; short-lived ones carry a sign-in through Google or GitHub from the start to the return; and one remembers the language you chose. If you use the help assistant without an account, a cookie (fb_help) lets you see your own conversations again, for 30 days. If you arrive through a partner's link, a cookie (ref) remembers which link it was for 30 days, so that the partner is credited if you sign up — it holds the link's code and nothing about you. One more (dvm) serves the abuse checks described in section 2. There is no advertising cookie here.

We use Google Analytics to count visits and see which pages help, on the site and in the console. If you are in the European Economic Area, the United Kingdom or Switzerland, it sets no cookie and keeps no identifier until you allow it in the banner; until then Google receives only cookieless signals (that a page was viewed, with no identifier) from which it estimates totals. Anywhere else it is on from the start. When allowed, Google Analytics sets its own cookies (_ga and _ga_…) for up to two years, and sees your browser, device, approximate location and the pages you open. Your answer is kept in a cookie (fb_consent) for a year, and one more (fb_eu) says whether the banner has to ask you. You can change your answer at any time with "Cookie settings" at the bottom of every page; saying no deletes the Google Analytics cookies. Advertising features are off, and nothing is sold.

8. Who else receives data

We use other companies to run the service. Each receives only what its job needs:

• AI model providers — the request itself and the answer, as described in section 4. OpenAI, Anthropic, Google, Microsoft and Amazon are the ones behind most models, Alibaba Cloud serves the DeepSeek, GLM, Kimi and Qwen models, and DigitalOcean, Inc. (United States) serves some of these as well as the gpt-oss, Gemma, Llama, MiniMax, MiMo, Ministral and Nemotron models; the catalogue names the vendor behind each, and which one serves a request can change.
• Stripe, for card payments — your email address, an account reference, the amount, and whatever you type on Stripe's own payment page. Stripe is the one that sees your card.
• NOWPayments and CoinGate, for cryptocurrency payments — an order reference, the amount and the currency.
• Resend, which delivers our email — the address we are writing to and the letter itself.
• Google, for Google Analytics — the pages you open, your browser and device, and an approximate location; with its cookies only if you allow them, as described in section 7.
• Our hosting providers in the European Union, which host our database, website, console and gateway — everything listed in section 2, and what passes through the service as it is used.
• Network and security providers that carry encrypted traffic between our service and the AI providers — the destination of the traffic, not its content.
• A storage provider which holds encrypted copies of our backups; they are encrypted before they leave us, with a key the provider does not have.
• The tools we use for our own bookkeeping and for notifications to us — for each payment the email address, the amount and the payment method, kept as accounting records; for a help request that needs a person or that the assistant could not answer, the email address and a reference to the conversation, not what was written; when two accounts look like one person taking a bonus twice, the accounts concerned and the reason.

We do not sell personal data, we do not share it for advertising, and we do not give it to anyone else except where the law requires us to — a court order, a lawful request from an authority, or a report we are obliged to make. Where we must disclose something, we disclose only what is required.

9. International transfers

Our own infrastructure is in the European Union. The providers that answer requests, the payment processors and the email service are mostly in the United States, so using this service means personal data leaves the United Kingdom and the European Union. Those transfers rely on the protections in our agreements with each company — the UK Addendum to the EU standard contractual clauses, the EU–US Data Privacy Framework where a company is certified under it, or an adequacy decision where one covers the destination. You can ask us at support@flintbeam.com which applies to which.

Requests to the models served through Alibaba Cloud (DeepSeek, GLM, Kimi and Qwen) may be processed in Alibaba Cloud's data centres in China as well as elsewhere. No adequacy decision covers China; if that matters for your work, choose a model served by another vendor — each model's page names who serves it.

10. How long we keep things

• Your account details: for as long as your account is open, and until the closing described in section 11.
• Sessions, sign-in attempts, email confirmation tokens and two-factor challenges: each is deleted automatically 90 days after it stopped mattering — after a session expired or was ended, after an attempt was made, after a token was used or expired.
• Request records: for as long as the payments they explain are kept, because they are what each charge on your balance is made of.
• Ledger entries and payments: for at least six years after the year they belong to, as UK tax and company law require, including after an account closes.
• Encrypted backups: recent copies for up to fourteen days, and daily copies in an encrypted archive kept indefinitely — an archive is not edited when a record inside it reaches the end of its retention, and it is opened only to restore the service.
• Support correspondence: as long as the matter is open, and up to two years afterwards.
• Conversations with the help assistant on our website: 30 days after the last message, then they are deleted automatically with any pictures attached.
• Local files you upload to the files endpoint: they expire 30 days after upload; their expiry is returned as expires_at.
• Responses you store on /v1/responses: 30 days, then they are deleted automatically; deleting one yourself removes it at once. Conversations you create: until you delete them, up to 1,000 live conversations per account. Creating a stored file, conversation or response requires a positive spendable balance; with $0 spendable, the request returns HTTP 402.
• The device, browser and connection identifiers used against bonus abuse (section 2): a connection's identifier 30 days after it was last seen, a device or browser identifier one year after it was last seen; for a closed account, all of them four months after it was closed. A one-way hash of an email address an account no longer uses, kept so that a bonus is not paid twice to one mailbox: four months. Copies of these hashes kept in our own records of decisions about two accounts go when the identifier itself does.
• Partner programme records: for as long as you take part, and payout records as long as the payments they explain are kept.

If you want something removed sooner, ask us at support@flintbeam.com. We will do it where the law lets us, and tell you which part we cannot remove and why — an accounting record we are required to keep is the usual reason.

11. Closing an account

Closing an account revokes every API key on it, ends every session, deletes your password, your name, your two-factor secret and your recovery codes, and releases your email address so that it can be used again — the address on the record is replaced with one that belongs to nobody. Stored files, conversations and responses are erased. Session and sign-in records are deleted automatically on the schedule above.

What stays is the accounting: the requests, the ledger and the payments, along with the identifier they hang from, the IP address the account was opened with, and the email address recorded with each payment in our bookkeeping. They are records of money moving, and they have to remain readable for the time the law requires. The device, browser and connection identifiers used against bonus abuse are deleted four months after the account is closed, as section 10 says.

12. Your rights

From the account page, without asking anyone, you can:

• Change your email address. We send a confirmation to the new address and tell the old one afterwards.
• Change your password, or set one if you signed up through a provider, using the reset link on the sign-in page.
• See and end every session on your account.
• Turn two-factor authentication on or off, and reissue recovery codes.
• Disconnect Google or GitHub, as long as another way to sign in remains.
• Close your account.

The law also gives you the right to ask for a copy of the personal data we hold about you, to have it corrected, to have it deleted, to object to how we use it, to ask us to restrict what we do with it, to receive it in a portable form, and to withdraw a consent you gave. Write to support@flintbeam.com from the address on your account and we will answer within one month. Where we cannot do what you ask, we will say which part and why.

13. Automated decisions

Spending ceilings are arithmetic you can see and set, rate limits are applied by rule to protect the service, and a refusal from a provider is the provider's. A suspension can be triggered automatically — by a reversed payment, or by traffic that looks like an attack — because waiting for a person would cost someone else money. What happens after a suspension is not automatic: a person reviews it, records the outcome and explains it, and you can appeal under the Model and Provider Terms.

14. Children

This service is not for children. Accounts are for adults, or for those old enough to enter a contract where they live, and we do not knowingly collect anything about anyone younger. If you believe a child has an account here, tell us at support@flintbeam.com and we will remove it.

15. How we protect data

• Passwords are hashed with argon2id, API keys are stored only as hashes, and two-factor secrets are encrypted with a key kept apart from the database.
• Access to stored data is restricted so that each part of the service can reach only what it needs, and one account can never read another's.
• Everything travels over TLS — between you and us, between us and the providers, and between our own components. The site is served with a content security policy that stops a model's answer from fetching anything from the network.
• Staff access requires two-factor authentication. Backups are encrypted and regularly tested.
• No security is perfect. If we learn of a breach that affects your personal data, we will tell you and the supervisory authority as the law requires, without undue delay.

16. Complaints

Tell us first at support@flintbeam.com — most things are quicker to fix directly. If that does not resolve it, you can complain to the Information Commissioner's Office, the UK supervisory authority for data protection, at ico.org.uk, or to the data protection authority of the country where you live.

17. Changes to this page

This page changes when the service does, and the date at the top says when it last did. If a change means we start doing something with your data that this page does not already describe, we will tell you by email at least 14 days before it starts rather than let you find it.