Loading page
Gondola is built so that the most sensitive thing you send us, your prompts, is something we never keep. This page says exactly what we store, what we do not, and who else touches your data.
Last updated: October 22, 2026
Prompts and completions are never written to disk. That includes your chat messages, system prompts, tool inputs and outputs, generated text, the contents of images you send, audio you upload for transcription, documents you submit for text extraction, text you submit for speech generation, source video clips up to 18 MiB we fetch from the link you give for video-to-video or upscaling, and the audio bytes we return. We do not store this content, and we do not store hashes of it (the only hashed request value we keep is the optional client cache-routing key described below, and the only response bodies we hash are upstream error responses and, when an image request comes back without a usable image, a response body of at most 4 KB, both described below). Requests are processed in memory, forwarded to the model, and the content is gone once the response finishes. For a transcription request we keep the clip's length in seconds, because that is what the request is priced on; never the recording or the transcript. For speech we keep the input's character count, never the text.
Naturally, the messages you submit for inference pass through our gateway to the model so they can be answered. Gondola processes them in memory and keeps none of their content. What happens on the model side depends on the model; see "Who else processes your data" below.
Account data: the wallet address you sign in with. For sellers, an encrypted copy of the Venice API key you deposit and the payout address you set.
Notification email: if you opt in to low-balance alerts or deposit receipts, the email address you add (encrypted at rest), whether it is verified, whether receipts are on and since when, when we last emailed you an alert, and which of your deposits have been sent a receipt. It is used only for the emails you asked for, and you can remove it at any time from /wallet, which stops them.
Feedback and contact messages: when you send us a message from the site, we store its text (up to 4,000 characters), the email address you leave if you add one, the wallet or seller account you were signed in with, the page you sent it from, and your browser's user agent.
API keys: a one-way hash of each key (we cannot recover the key itself), its label, optional expiry, spend limits and max price, and when it was last used.
Seller API tokens: a one-way hash of each token, its first 9 characters for display, its label, whether it may change prices and its floor factor, and when it was created, last used and revoked.
Per request: the model, token counts, timestamps, latency, cost and settlement amounts and fee rates, and the model id used. We also note which API endpoint you called, the kind of client software your request identified itself as (a short category such as "OpenAI Python SDK" or "curl", never the full user-agent string), the model name exactly as you spelled it when it differed from our catalog name, and which automatic adjustments we made to the request (for example a stop list shortened to a model's limit), so we can find and fix compatibility problems. We also note the effective price ceiling applied to the request (your x-gondola-max-factor header, the max price set on your API key when the request carries no header, or the factor derived from an OpenRouter provider.max_price), rounded down to the hundredth and capped at 1, to measure which prices buyers accept and to set the automatic price sellers can choose for their keys. For the same purpose we note the lowest price an automatically priced seller was listing for that model when your request was routed, a market price that says nothing about you. On text requests we also note which end-user id fields your request carried (user, safety_identifier, anon_user_id or metadata.user_id): the field names only, never their values. A request we turn away before it reaches a model is counted only as an hourly total per endpoint, error type and model. When a request is turned away because of your own price ceiling, we add that ceiling, rounded down to the hundredth and weighted by what you paid at that same ceiling over the last 7 days, to an hourly total that does not record who you are, kept for 90 days. To count you once per hour at each ceiling we keep a short-lived marker linked to your API key and that ceiling, which an hourly job deletes once it is more than 24 hours old. On a failed request we also store a hash of the upstream error text (when an image request comes back without a usable image, a hash of that response body if it is at most 4 KB, and nothing for a larger one), a short fixed label for why it failed (for example, a tool call cut off at the token limit) and a structural fingerprint of the request shape (how many messages and their roles, which kinds of content parts and which parameters were present), never the content itself. If your client sends its own prompt_cache_key (an optional cache-routing hint), we store a 12-character one-way hash of that value so cache problems can be diagnosed: never the key itself, and nothing at all when Gondola derives the key for you. Pick a key that does not embed sensitive data; a session or conversation id is ideal.
Payments: on-chain deposit and payout transactions. These are public on the Base blockchain by their nature, independent of us.
Video and audio generation: the model provider holds a finished clip for a short time. When your client confirms it was delivered, we ask the provider to delete it at once; if your client never confirms, we ask about a day after delivery and retry every hour until the provider confirms it is gone. We store the job id, never the media.
Source clips over 18 MiB: on the models that accept them, we keep a private copy of the clip you link (on Vercel Blob storage) so the model can read it while your job runs. It is reachable only through signed links that expire, never publicly, and we delete it within about an hour after your client retrieves the result, or about seven hours after a job that failed or was never collected (a day and a half at most). Clips up to 18 MiB are never stored.
Secrets we hold at rest (deposited Venice keys, and the private keys of the deposit addresses used to receive top-ups) are encrypted with AES-256-GCM.
We use the data above only to run the service: to authenticate you, meter and settle usage, pay sellers, keep the marketplace secure, measure aggregate site traffic, and publish aggregate market statistics at /stats. We do not sell your data, use it to target ads, or send it to ad networks.
We use first-party cookies only: a session cookie to keep you signed in (gondola_wallet, up to 7 days, or gondola_vk when a seller signs in with a Venice key, also up to 7 days), a short-lived login nonce, and a referral-attribution cookie (gondola_ref, up to 90 days). We do not use third-party advertising trackers or ad-network tags. Site traffic and page speed are measured with Vercel Web Analytics and Vercel Speed Insights, both cookieless, neither storing a persistent identifier; see the next section for what they process.
Venice AI receives the content of your requests and routes them to the model, and it assigns each model a privacy tier. Venice classifies private models as zero data retention: prompts are processed for inference and not stored. For anonymized models, Venice forwards your request to a third-party inference provider with your identity stripped: usually the model's maker (for example OpenAI, Anthropic or Google), but for open-weight models and some relayed models Venice does not name the host. That provider sees the content and handles it under its own terms, which can include retention. Each model's tier is shown on /models and published as the privacy field on /v1/models. When a model carries no tier, its handling is not published, so assume a third party may see and keep the content. Whatever the tier, Gondola stores and logs no prompt or response content. If you turn on web scraping, Venice has the URLs in your latest message fetched by its scraping provider, Firecrawl, and passes the page text to the model. If you ask for a transparent background on a model Venice renders transparency for, the model makes it directly and the image goes to no other model. On a model it does not, the image the model made is sent on, through Venice, to the same model family's image-edit model, handled under that model's tier above, and when needed to Venice's background-removal model (BRIA), which carries no published tier, so assume a third party may see it. Gondola computes the transparency in memory and stores no image. The background-removal endpoint sends the image you submit to that same BRIA model.
Vercel hosts and fronts the application, and provides our site analytics: aggregate page views (page URL with any non-campaign query parameters stripped before sending, referrer, country-level location, browser and device class, timestamp) and page-speed samples (Core Web Vitals timings for the page URL and its route pattern, the URL stripped the same way, with country-level location, browser, operating system, device class and connection type), both collected without cookies or any persistent identifier, and never involving prompt or completion content. Railway hosts the database. Privy handles wallet and email sign-in. Resend delivers the optional notification emails, so it receives your address and the text of each one. A deposit receipt carries the amount, the transaction hash and your wallet address, so turning receipts on lets Resend link your email address to your wallet and its deposits on Base. A Base RPC provider relays on-chain reads and transactions. If you choose to pay from another chain, public RPC providers for those chains read your connected wallet's balances, and your browser contacts Relay directly, so Relay, which routes the transfer to Base, receives your IP address, your wallet address and the transfer details.
The Base blockchain records deposits and payouts publicly.
The providers above may process data in countries other than yours. Using the service means you accept that cross-border processing.
We keep account and usage records for as long as needed to run the service and to keep our accounting and solvency reporting correct; there is no fixed deletion schedule. You can deactivate API keys at any time from /keys, and sellers can revoke a deposited key from /sell: new requests stop at once, and its encrypted key material is deleted once its last in-flight request settles and any video or audio it produced has been cleaned up. To request access to, correction of, or deletion of your data where applicable, contact us and we will handle it directly after verifying you control the wallet in question.
Secrets are encrypted at rest and access is limited to what the service needs to operate. No system is perfectly secure; if a breach affects your data, we will notify affected users and the relevant authorities where the law requires it.
Gondola is not intended for anyone under 18, and we do not knowingly collect their data.
We may update this policy as the service evolves; the date at the top changes when we do.
support@gondola-ai.com