What this site collects, and what it does not.

01Who is responsible #

The controller of personal data processed through debyko.com, studio.debyko.com, agent.debyko.com, docs.debyko.com, api.debyko.com and mcp.debyko.com is MB Debyko, company code 308157191, Girulių g. 10-201, LT-12112 Vilnius, Lithuania, support@debyko.com.

02What is collected #

When you visit: every page loads Google Tag Manager, which delivers the consent banner and, once you allow it, the analytics. Loading it tells Google your IP address and browser details, as fetching anything from another site does.

The banner is CookieHub. It stores your answer in a cookie in your browser — set whether you accept or decline, so the site stops asking — and you can change the answer at any time from the banner’s link in the footer.

If you accept analytics: Google Analytics 4 sets its own cookies and sends Google the visit — the pages you open, the page that sent you, your device and browser, and a location derived from your IP address. We see it as counts and trends, never a name. If you decline: no analytics cookie is set, nothing is sent to Analytics, and the site works the same.

When a page breaks: your browser reports the error to Sentry — the message, where in our script it happened, the page address without its query string, the browser and system, and for a signed-in reader the id and the email address of the account, so that a report can be tied to the person who met the fault; for a reader who is not signed in and has accepted analytics, a random identifier kept in the cookie dk_anon, which recognises the same browser in a later report or recording. E-mail addresses and API keys found in a message are removed before it leaves the browser. Without your acceptance of analytics no cookie is set for it, and nothing is kept in browser storage in either case; Sentry is set not to keep the IP address. The scripts come from our own domain, not from Sentry.

When our servers break or run slowly: our own services report to the same Sentry — the API, the account and Agent services, the data collectors and the MCP server. An error report holds the message, where in our code it happened, the address of the request without its query string and what the service logged just before; a performance trace holds, for a request or a call between our services, its route, how long it took and the status, and for a page in your browser how fast it loaded and how long its calls to our API took, with the address of each without its query string. Before anything leaves, e-mail addresses, API keys, tokens and link codes are removed. Our servers never tell Sentry who you are and never send your IP address, a cookie, a header that carries a key, or what you sent in a request (for the MCP server, the arguments of a tool call). A trace from your browser carries the same identifiers as an error report from it, described above. The share of requests and page loads that are traced is a setting of ours.

Session Replay only if you accept analytics: the page you see is recorded as you see it — text, form fields and, on your account’s pages, your address — with your clicks and the pages you move between, so that a fault can be reproduced. Only an API key or a webhook signing secret, where a page shows one, is left out of the recording. Sign-in pages are never recorded. A guest’s recording stays in the browser’s memory and is sent only if an error follows; a signed-in reader’s session is sent as it goes. An answer given on debyko.com counts on studio.debyko.com and agent.debyko.com. Decline, or change the answer from the banner’s link in the footer, and no recording is made or sent.

When you send a form: the Contact sales and Join the waitlist forms send what you type — your email address, and for a sales request the organisation, the engagement and the venues, instruments and period; for the waitlist the product you are interested in — to a function on this site, which passes it on by email to support@debyko.com through Mailjet. The notification also carries your IP address and country, so that abuse can be recognised; they are not stored anywhere else. To limit abuse the function counts requests per IP address in Cloudflare’s key-value store; each count expires by itself after ten minutes.

When you write to us directly: the support@debyko.com links, and the address shown if a form cannot send, open your own email app. What you send is your email address, your name if your email app includes it, and what you write.

When you open an account: your email address and the time the account was opened. Signing in works by an email sent to that address, carrying a six-digit code and a link; both are valid for fifteen minutes and are stored only as hashes until then. While you are signing in, a cookie on the sign-in pages remembers for an hour which request this browser made, so that the code you type is checked against it. The account keeps, for each API key, its first twelve characters and a hash of the rest — never the key itself — plus the plan, the dates it was issued, expires or was revoked, and a label you give it. A session cookie is set only after you sign in, only on your account pages, and only to keep you signed in. With it a second cookie is set for debyko.com and its subdomains: it holds no address, no key and no identifier — only the fact that you are signed in — so that every DEBYKO page can show your account in its header. A page that finds it asks your account for your email address and shows it there; both cookies go when you sign out.

Your public profile. If you set one on your account page: a public name, a handle, a short bio and one link. These are public by design. The handle names your page on arena.debyko.com; where your account has Arena data, your public name, bio and link are shown there too. Your avatar is not a photo: it is a pattern generated from your handle, so it is public with the handle. The account also keeps a random avatar seed, which is not shown anywhere. A handle you change is kept for thirty days so that its old address can redirect to the new one. Handles that existed in Arena before accounts were carried into the account.

Where you are signed in. For each session, a short device label worked out from your browser’s User-Agent (for example “Chrome on macOS”), the time of the session’s last request (rounded to five minutes) and which site it belongs to, Studio or Agent. The User-Agent itself and your IP address are not stored for this. Your account page lists the sessions so that you can end one; the record goes with the session.

How you arrived (sign-in and connection steps). So that we can see where signing in and connecting fail — an email the mail service refused, a code that did not work, an AI client that began to connect and was never answered — each step is recorded: a sign-in requested; the email accepted or refused by the mail service (with the service’s message id, or a short error code); a code or link entered, right or wrong; an account opened or entered; and, for an AI client, the connection started (the client’s name and the host it redirects to), the consent page shown, your answer, and the first token issued or the reason it was refused. A step holds its time, its outcome, where you came from (this site, Studio, Agent, your account page or an AI client) and your account — or, before the account exists, a keyed one-way hash of your email address (a secret key only DEBYKO holds), never the address itself. For the steps you take in your own browser it also holds your network — your IP address shortened to its first 24 bits (IPv4) or 48 bits (IPv6), for example 203.0.113.0/24, which names a network and not a connection — and your browser’s User-Agent, cut to 256 characters. A sign-in code, a link, a token, a cookie or a key is never recorded. DEBYKO’s own staff and test accounts are recorded too, marked as such, so that they can be left out of our counts. When an AI client later calls our API, the first of its calls is found in the call record described under “When you use a key”; nothing more is added for it.

Welcome email and product updates. When an account is opened, one welcome email goes to its address, once: what the account has, and one first step suited to where you came from (an AI client, Studio, the API documentation or the Agent). It is sent through Mailjet from hello@debyko.com, carries no tracking pixel and no rewritten links, and is not sent to the accounts opened before this was introduced. DEBYKO keeps a record of it with the account — whether it was sent, the number of tries, Mailjet’s message id or a short error code, and where you came from — never its text. Separately, your account page has an optional box, Product updates, which is never ticked for you and is independent of signing in and of connecting an AI client. If you tick it, DEBYKO records when, where on the site and which wording you saw; you can untick it on the account page at any time, and every product-update email carries a link that unsubscribes you in one click with no sign-in. An address that has unsubscribed is kept on a suppression list, as a keyed one-way hash of the address and not the address itself, so that product updates are not sent to it again; subscribing again takes it off. Sign-in codes, alerts you set up and billing messages are separate and are not affected by it.

Connecting an AI client (OAuth). When you connect an AI client to mcp.debyko.com, we record the client's registration (its name and redirect address), the account you authorised, the time of authorisation and the time each token was issued or revoked. Tokens are tied to your account and its plan and can be revoked from your account page at any time. We do not receive the content of your conversations with the AI client — only the tool calls it makes to our API, which are recorded like any other call made with your key (see “When you use a key”).

When you use a key: the API counts requests per key, per hour and per endpoint class, and the seconds a live stream stayed open. These counts enforce your plan’s limits and are the basis of usage shown in your account. Beside the counts, every call made with your key is recorded — a request you send to the API yourself, and a call an AI client you connected makes through the MCP tools, the free ones included — so that we can see where requests fail and what the service is asked for. A record holds the time, your account, which key made the call and whether it is a key you made or an AI client’s connection, the endpoint and the name of the MCP tool, the status and error code of the answer, how long it took, and the arguments of the call that describe a market query: the instruments, venues and layers, the time window, the timeframe, the limit and the units, and the DQL text (cut at 2,000 characters). When an AI client uses the Agent tools, the alert rule’s DQL text and the label you gave it are kept; channel addresses and webhook URLs, tokens and secrets, Telegram link codes and message bodies are not stored at all. Neither are your key, the Authorization header, your email address or your IP address. Your IP address is not part of the call record; it is used for short-lived rate counts that expire within an hour and, when you sign in or connect an AI client, in shortened form for the steps described above under “How you arrived”.

When you subscribe: checkout uses Stripe Managed Payments. We receive from Stripe your email address, plan, subscription status and dates, and customer and subscription identifiers needed to manage access. We never receive your card number. We also keep, with the subscription record, the brand and last four digits of the payment method as Stripe reports them, to show on your account page.

If you arrive by a partner’s link. A link of our referral programme (debyko.com/r/ and a partner’s handle) sets the cookie debyko_ref for debyko.com and its subdomains for 30 days. It is a functional cookie of the referral programme, set only when you open such a link and not asked about in the banner: it holds only the partner’s public handle and the time of the click — nothing about you — and a later partner link does not replace it. On another browser or device the sign-in page takes the partner’s referral code instead, if you type it. If you open an account while it is there, the account records which partner sent you, once; the partner sees the count of accounts they referred and of those that pay, never your address or your plan. When such an account pays, we record for the partner’s commission the invoice and charge identifiers, the amount paid, tax, Stripe’s fee and a fingerprint of the card that Stripe gives us (to refuse a partner paying for themselves), never the card itself.

If you are a partner. We keep the date we approved you, the USDC address on Base you give us for payouts, the commissions of the accounts you referred and each payout we send, with its transaction hash.

On-chain payments (x402). If you pay for an API call with an on-chain payment (x402, USDC on Base), we record the transaction hash, the paying address, the amount, the endpoint class and the settlement time. This record is accounting evidence and is kept for 10 years as required by Lithuanian accounting law. A wallet address is not linked to a name unless you also hold an account with us. The call itself is recorded in the call record described above under a one-way hash of the paying address instead of an account; the address is not in that record. Payment verification and settlement are performed by Coinbase Developer Platform as facilitator under its own privacy policy.

At the providers the pages use: the technical data of each request your browser makes — IP address, time, requested address and browser details — as described in section 04.

03Why, and on what basis #

• A sales request is used to answer it and to prepare a scope — steps taken at your request before a contract (GDPR Art. 6(1)(b)).
• A waitlist address is used for one message when the chosen product opens — your consent (Art. 6(1)(a)), which you can withdraw at any time by writing to us.
• Request data at the hosting and delivery providers is processed to deliver the pages and keep them secure — legitimate interest (Art. 6(1)(f)).
• Error reports and performance traces, from your browser and from our servers, are processed to find and fix faults and slowness in the service — legitimate interest (Art. 6(1)(f)). Session Replay is recorded, and the dk_anon cookie set, only on your consent (Art. 6(1)(a)), which you can withdraw at any time from the banner; withdrawing deletes the cookie.
• Account, key and usage data are processed to provide the service you signed up for and enforce its limits — performance of a contract (Art. 6(1)(b)).
• The sign-in and connection steps are processed to find and fix the failures of signing in and connecting, to count how many people finish them, and to recognise abuse — legitimate interest (Art. 6(1)(f)).
• Call records are processed to find where requests fail, to answer questions about a call and to understand what the service is used for — legitimate interest (Art. 6(1)(f)).
• The welcome email is sent, once, to tell a new account holder what the account has and how to start — performance of a contract (Art. 6(1)(b)). Product updates are sent only on your consent (Art. 6(1)(a)), given by ticking the box on your account page and withdrawn at any time by unticking it or with the link in any message; the suppression list that keeps an unsubscribed address from being written to again rests on our legitimate interest in honouring your choice (Art. 6(1)(f)).
• The public profile is shown because you chose to fill it in and publish it — your consent (Art. 6(1)(a)), withdrawn by clearing the fields or by writing to us. The session device label is processed to show you where you are signed in and to let you end a session — legitimate interest (Art. 6(1)(f)). The card brand and last four digits are processed to show you which payment method a subscription uses — performance of a contract (Art. 6(1)(b)).
• Subscription and invoice records are kept because accounting law requires it — a legal obligation (Art. 6(1)(c)).
• The referral cookie and the partner recorded with an account are processed to pay a partner the commission our programme promises for the accounts they bring — legitimate interest (Art. 6(1)(f)); a partner’s payout address and payouts — performance of the partner terms (Art. 6(1)(b)) and accounting law (Art. 6(1)(c)).

Nothing is sold, and nothing is shared for advertising.

04Who else sees a request #

• DEBYKO uses OpenAI as a subprocessor for optional AI rule building and explanations. When you request these features, we send your prompt, relevant rule DQL and public DQL documentation to OpenAI. We do not include account email, exchange keys or notification credentials. Avoid including personal or confidential information in prompts.
• Cloudflare, Inc. hosts debyko.com (Cloudflare Pages), runs the function that sends the forms, and sits in front of the market-data API. It processes the technical data of every request, and receives network-error reports from browsers that support them, under its own retention rules.
• Google serves the two typefaces the pages use (Google Fonts) and delivers Google Tag Manager on every page. When your browser fetches either, it sends Google its IP address and browser details. If you accept analytics, Google Analytics 4 also receives the visit described in section 02.
• CookieHub (CookieHub ehf, Iceland) shows the consent banner and records your answer. Its script is delivered through Google Tag Manager.
• Sentry (Functional Software, Inc.) receives error reports from your browser always, and a Session Replay only if you accept analytics, as section 02 describes; it also receives the error reports and performance traces of our own servers, which do not say who you are (section 02). The data is stored in the EU, in Frankfurt. Your browser contacts Sentry’s ingest only to send a report or a recording; nothing is loaded from Sentry.
• DEBYKO’s market-data API serves figures to the site and Studio. Public pages read it server-to-server and share short-lived cached results; signed-in Studio reads go through the account session gateway and use the account’s plan and usage limits. Cloudflare and the hosting provider process the network data needed to deliver these requests.
• Mailjet (Sinch, EU) delivers the Contact sales and waitlist forms to support@debyko.com: the form’s content, your email address as the reply-to, and your IP address and country. If a delivery fails, Mailjet’s error message is written to the function’s log at Cloudflare.
• Apple hosts the support@debyko.com mailbox (iCloud Mail); messages you send us, and the form notifications, are stored there.
• Stripe handles checkouts, payments, applicable indirect taxes and invoices through Managed Payments. Customers interact with Link at checkout and for post-purchase support. Stripe sends us the subscription data listed in section 02 and processes payment information under its own privacy notice.
• Mailjet (Sinch, EU) also delivers sign-in emails, subscription emails, the welcome email and, if you subscribe, product updates.
• The account and API at api.debyko.com and studio.debyko.com, operated by MB Debyko on infrastructure rented from Microsoft (Azure, EU region), store account, key and usage data as described in section 02.
• For requests paid with x402, the payment header (signature, amount, payer address) is sent to Coinbase Developer Platform for verification and settlement. The API request itself — the query, the instruments, the response — is not shared with them.

Cloudflare, Google, Apple and Sentry’s operator (a US company) may process data outside the European Economic Area under their own safeguards for such transfers.

05How long it is kept #

• A waitlist address: until the one message is sent when the product opens, then deleted.
• A sales request and the correspondence that follows: for as long as the conversation or the engagement lasts, and afterwards only as long as the law requires records to be kept.
• Your IP address in the form’s request count: ten minutes, in Cloudflare’s key-value store, then it expires.
• Request data at Cloudflare and Google, and delivery records at Mailjet: for the periods those providers set.
• Your answer to the banner, in CookieHub’s cookie: for the period CookieHub sets it, or until you change the answer.
• Error reports, performance traces and Session Replay at Sentry: for the retention set in DEBYKO’s Sentry project, at most ninety days, then deleted by Sentry.
• dk_anon — set for debyko.com and its subdomains (studio, agent), only after you accept analytics: a random identifier that recognises your browser in error reports and recordings when you are not signed in. It holds nothing else. It lasts one year, and is deleted when you withdraw analytics.
• Analytics cookies in your browser and the visit data at Google: for the periods Google sets and the retention chosen in the Analytics property.
• Account, key and plan data: for as long as the account exists, then deleted within thirty days of closure.
• Public profile: for as long as the account exists, then deleted within thirty days of closure; a changed handle’s old address: thirty days. Session device label and last use: deleted with the session. Card brand and last four digits: with the subscription record, as the subscription records item below describes.
• Usage counts per key: twelve months, then deleted.
• Call records (the calls made with your key and what they asked, as section 02 describes): ninety days, then deleted; deleted with the account when it is closed. A call paid with x402 is kept ninety days too, under the hash of the paying address.
• Sign-in and connection steps (as section 02 describes): the network and the User-Agent of a step are deleted after thirty days; the step itself after ninety days, or with the account when it is closed earlier. The hash of an address that never became an account goes with the ninety days.
• The record of your welcome email, and your consent to product updates (each time you ticked the box, with the time, source and wording, and the time you withdrew it): for as long as the account exists, then deleted with it within thirty days of closure. An address that unsubscribed from product updates stays on the suppression list until you subscribe again.
• Connecting an AI client (OAuth): access tokens are deleted when they expire, after one hour, and refresh tokens when they expire, after thirty days. A connection you authorised is kept until you revoke it or your account is deleted; a revoked one is deleted thirty days after the revocation. A client's registration is deleted one day after it was made if it was never used, and after ninety days without use if it holds no connection.
• Subscription and invoice records received from a payment provider: for as long as accounting law requires, currently ten years.
• debyko_oauth — set on debyko.com for 15 minutes during an OAuth authorisation, to tie your login to the authorisation request. Deleted when the flow completes or expires.
• debyko_signin_from — set on the sign-in pages for 15 minutes when you come to sign in from a link in Studio or in the documentation; it holds only the word studio or docs and, from Studio, the code of the instrument you were looking at (BTC), so that signing in can bring you back to it. Deleted when you have signed in or after 15 minutes. debyko_first_step — set for one year on your account pages only when you press Dismiss on the card that suggests a first question to ask a connected AI client; it holds only 1.
• debyko_ref — a functional cookie of the referral programme, set for 30 days only when you open a partner’s referral link; it holds the partner’s handle and the time of the click. Which partner referred an account is kept with the account; commissions and payouts are accounting records, kept for 10 years.
• Sign-in code and link hashes: fifteen minutes, then deleted; the cookie of a sign-in in progress: one hour; session cookie and the signed-in marker: until you sign out or thirty days.

06Your rights #

You can ask for access to, correction or deletion of your data, restriction of its processing or a copy of it, object to its processing, and withdraw a consent you gave — by writing to support@debyko.com. You can also complain to the State Data Protection Inspectorate of Lithuania (Valstybinė duomenų apsaugos inspekcija).

—Changes to this page #

• 2026-09-18First publication of this page.
• 2026-09-18The Contact sales and waitlist forms send through a function on this site and Mailjet instead of opening your email app; Mailjet added as a processor, with the IP address and country the notification carries. The request count per IP address is kept in Cloudflare’s key-value store for ten minutes.
• 2026-09-22Accounts, API keys, usage counts and subscriptions added; a payment provider added as merchant of record (Stripe since 2026-10-05); Microsoft Azure added as hosting for the account and API; Mailjet now also delivers sign-in links; the session cookie set after sign-in described.
• 2026-09-24Google Tag Manager added on every page; the CookieHub banner added, with the cookie that records your answer; Google Analytics 4 added, running only if you accept. Sections 02, 04 and 05 describe all three.
• 2026-09-29The controller is MB Debyko, company code 308157191, which operates DEBYKO and held the payment provider account (Stripe since 2026-10-05). The market-data API the pages read is named in section 04 as run by a separate company.
• 2026-09-30One header on every DEBYKO page: after sign-in a second cookie, holding nothing but the fact that you are signed in, lets debyko.com show your account in its header, and signing out there ends every session of the account. The sign-in email carries a six-digit code as well as the link, and a cookie that lasts an hour remembers the sign-in in progress. Sections 02 and 05 describe both.
• 2026-10-01On-chain payments (x402) added: what is recorded when you pay for an API call with USDC on Base, how long it is kept, and that Coinbase Developer Platform verifies and settles the payment as facilitator. Section 02 describes it.
• 2026-10-02Connecting an AI client to mcp.debyko.com with OAuth added to section 02, and the debyko_oauth cookie to section 05.
• 2026-10-05Added Stripe Managed Payments for subscriptions.
• 2026-10-06mcp.debyko.com named in section 01. Section 02: an AI client's tool calls are counted like any other API request, not logged. Section 05: how long OAuth tokens, connections and client registrations are kept.
• 2026-10-08Section 05: subscription and invoice records are kept from any payment provider DEBYKO has used, not only Stripe.
• 2026-10-13Sentry added as a processor (Functional Software, Inc., data stored in Frankfurt): error reports from your browser always, Session Replay only if you accept analytics. Sections 02 to 05 describe both.
• 2026-10-13Call records added: every call made with an account’s key, through the MCP tools or directly, is recorded with its time, key, endpoint, tool, status, duration and the market-query arguments (never secrets, keys, email or IP addresses), for ninety days; an x402 call is recorded under a hash of the paying address. Sections 02, 03 and 05 describe it.
• 2026-10-13Session Replay records the page as you see it; only API keys and webhook signing secrets are left out.
• 2026-10-13Sentry now receives the id and the email address of a signed-in reader with an error report or recording, in place of a hash of the id. After you accept analytics, a random identifier in the new cookie dk_anon (one year) recognises a browser that is not signed in; withdrawing analytics deletes it. Sections 02, 03 and 05 describe both.
• 2026-10-14Sign-in and connection steps recorded: each step of signing in and of connecting an AI client is kept with its time, outcome and origin, under your account or a keyed one-way hash of your email address; for the steps in your browser, your network (IP address shortened to /24 or /48) and User-Agent are kept thirty days, the step ninety days. Never a code, link, token, cookie or key. Sections 02, 03 and 05 describe it.
• 2026-10-14Welcome email and product updates added: one welcome email to a new account (through Mailjet, with a record of whether it was sent, never its text), and an optional, never pre-ticked consent to product updates on your account page, withdrawn with one click, with a suppression list for the addresses that unsubscribed. Sections 02 to 05 describe both.
• 2026-10-14Two small cookies on the account pages: debyko_signin_from (15 minutes, the word studio or docs and an instrument code) so that signing in from Studio returns you to the instrument, and debyko_first_step (one year, only if you dismiss the first-question card). Section 05 describes both.
• 2026-10-14Sentry now also receives error reports and performance traces from our servers (the API, the account and Agent services, the data collectors and the MCP server) and performance traces from your browser (page loads and calls to our API), with addresses, keys and tokens removed; the servers send nothing that identifies you. Sections 02 to 05 describe it.
• 2026-10-16OpenAI added as a subprocessor for optional AI rule building and explanations in section 04.
• 2026-10-26Section 02: the public profile (public name, handle, bio, link, avatar seed, shown in Arena), the device label and last use kept for each session (no IP address, no User-Agent), and the card brand and last four digits from Stripe. Sections 03 and 05 give their basis and how long each is kept.
• 2026-10-26Section 02: the generated avatar is drawn from your handle; the stored avatar seed is not shown.
• 2026-10-30Referral programme: a partner’s link sets the functional cookie debyko_ref (30 days, only on the click, the partner’s handle only), and the sign-in page takes a partner’s referral code; an account opened while it is there records the partner, and a paid invoice of that account records what the partner’s commission needs. Partners’ payout addresses and payouts are kept. Sections 02 and 05 describe it.

Each later change is added here with its date.