Privacy Policy
This Privacy Policy explains how Byte Imagination Roger Zacharczyk (trading as Byte Imagination, "we", "us") processes personal data in connection with the online service made available on the domain on which this Policy is published (the "Service").
This Policy applies to data we process as controller (account, billing, support, marketing). When we process personal data contained in Customer Data on your instructions, we act as processor under the Data Processing Agreement.
This Policy applies to you whether you hold an Account, use one as an Authorised User whom the Account Owner invited, or have received an invitation to one. "Account", "Account Owner", "Authorised User" and "Customer" have the meaning given in the Terms of Service.
1. Controller
- Controller: Byte Imagination Roger Zacharczyk
- Registered seat: Ludwika Kondratowicza 59/21, Warsaw, Poland
- Tax ID: PL7551870628
- Privacy contact: privacy@byteimagination.com
We have not appointed a Data Protection Officer. Based on our current processing activities and scale, appointment of a Data Protection Officer is not mandatory under Article 37 GDPR. We reassess this determination periodically and whenever our processing activities materially change. privacy@byteimagination.com is the single point of contact for all privacy matters.
2. Categories of personal data we process
| Category | Examples | Source |
|---|---|---|
| Account data | email address, hashed password, account creation date, email-address-verified timestamp, language preference | Provided by you at sign-up or when you accept an invitation |
| Account name | the name of the Account, shown to its Authorised Users and in invitations. It is a label the Account Owner chooses and may contain personal data if the Account Owner enters it; where the Account Owner has not given a name, it is the Account Owner's email address until the Account Owner changes it | Provided by the Account Owner at sign-up |
| Membership data | the fact that you are an Authorised User of an Account, your role in it, and the date you joined | Provided by the Account Owner and generated by the Service |
| Invitation data | the email address the Account Owner entered when inviting you, the name of the Account shown in the invitation, a short-lived hash of the single-use invitation token, and its issue, expiry and use timestamps | Provided by the Account Owner. If you were invited, we received your email address from the Account Owner and not from you |
| Actor identifiers | the identifier of the user who performed an action in the Service. In the activity log of the Service it is part of the Customer's data; in our security records it is the record of who created each API Key, kept as long as the key's audit history (Section 6) | Generated by the Service |
| Account verification data | short-lived hash of a single-use verification token sent to your email address, with its issue and expiry timestamps. The verification link itself is shown to you only once, in the email; we never store its plaintext form | Generated by the Service at sign-up and at every re-issue |
| Password recovery data | short-lived hash of a single-use password-reset token sent to your email address, with its issue, expiry and (where applicable) consumption timestamps. The reset link itself is shown to you only once, in the email; we never store its plaintext form | Generated by the Service when you request a password reset |
| Abuse-prevention data | short-lived signature of an accepted proof-of-work captcha challenge submitted with your sign-up or waitlist form. The signature is a non-reversible computational artefact and does not identify you | Generated by the Service when you submit the sign-up or waitlist form |
| Authentication data | API key (stored as a cryptographic hash), the human-readable label you assign to each key when creating it, session cookies, last login timestamp, key revocation timestamp, per-API-key usage records (timestamp, IP address, user agent, one row per authenticated request) | Generated by the Service; the API key label is supplied by you |
| Legal acceptance records | one row per legal document version you have accepted: timestamp of acceptance, IP address at time of acceptance, user agent, acceptance method (sign-up, explicit update, migration), language of the version shown to you, and — for an acceptance by the Account Owner — the Account on whose behalf it was given | Generated by the Service when you accept a published version of these Terms, the Privacy Policy, the DPA, or a per-Service Additional Terms |
| Billing and transaction data | name, billing address, country, VAT identifier (where provided), Subscription tier, transaction id, last 4 digits of payment card | Collected by Paddle as Merchant of Record and shared with us for fulfilment |
| Billing linkage identifiers | Reference codes that link your account in our system to your billing record at our payment processor. These identifiers do not contain payment-card information; the payment information they reference is held by our payment processor as Merchant of Record. | Received from our payment processor when your subscription is created |
| Usage data | API call counts, endpoint paths, response status, request and response bodies (subject to redaction of authentication and authorization headers, cookies, and common secret fields), trace identifiers, timestamps, IP addresses, user agents | Generated by your interaction with the Service |
| Data export records | the timestamp of your most recent data export request (a single value per user, and a separate one per Account for the export of the Account's data, used only to rate-limit the self-service export) | Generated by the Service when you use the self-service data export |
| Support data | content of messages you send to us, attachments | Provided by you when contacting support |
| Marketing data (optional) | opt-in to product updates, opens/clicks of marketing emails | Provided by you on opt-in |
| Waitlist data | email address, IP address at time of submission, timestamp of submission | Provided by you when you join the pre-launch waitlist on the public site |
| Outbound message records | the emails the Service sends you — the recipient address, the subject, the message text, which of our fixed templates produced it, the times it was queued and handed to our email provider, whether we succeeded in handing it over, and the identifier our provider assigned to it. Whether it then reached you is a separate record, below | Generated by the Service each time it sends you an email |
| Delivery-event records | what our email provider reports back about a message it handled for us — delivered, bounced, or reported as spam — including the recipient address and message identifiers contained in that report | Received from our email provider |
| Email delivery block state | whether we have currently stopped sending you email, when that started, and which of three things caused it — a permanent delivery failure, a spam report, or the closure of your account. This is our own classification of the cause; it does not include the text your mail provider sent us, which is held only as a delivery-event record above | Generated by the Service |
We do not intentionally collect special categories of data under Article 9 GDPR or data of children under 16. Do not submit such data through the Service.
The Service you are using may process additional categories of personal data that are specific to the features it provides. Where that is the case, those categories, their purposes, legal bases, and retention periods are set out in the Privacy Supplement for your Service. Where a Privacy Supplement is shown alongside this Policy, it supplements and forms part of this Privacy Policy.
3. Purposes and legal bases
| Purpose | Legal basis (GDPR) | Notes |
|---|---|---|
| Provide the Service: account creation, authentication, API serving, quota enforcement | Art. 6(1)(b) — performance of a contract | |
| Giving access to an Authorised User and keeping that access running: user account, sign-in, role | Art. 6(1)(b) — performance of the contract with you about the rules of using the Account; to the extent that contract is not accepted as the basis, Art. 6(1)(f) — legitimate interest of the Customer and of us in giving the person the Customer chose access to the Account | You enter into that contract when you accept the invitation (Terms of Service, Section 3b) |
| Showing the users of an Account to the Account Owner and to each other | Art. 6(1)(b) and Art. 6(1)(f) — legitimate interest of the Customer in knowing who uses its Account | See Section 4 |
| Sending an invitation and keeping it until it is used or expires | Art. 6(1)(f) — legitimate interest in letting a person nominated by the Account Owner join the Account | The invitation tells you who we are, where we got your address and where to find this Policy |
| Security and audit records identifying who acted | Art. 6(1)(f) — legitimate interest in protecting the Service | These are the per-API-key usage records and the records of who created each API Key; see Section 6 |
| Email-address verification at sign-up: confirming that the address you provide is one you control before granting access | Art. 6(1)(b) — performance of a contract | A short-lived verification token (stored as a cryptographic hash) is sent to your email address; clicking the link confirms control. Unconfirmed addresses cannot complete sign-up |
| Password recovery: allowing you to regain access to your account if you forget your password | Art. 6(1)(b) — performance of a contract | A short-lived password-reset token (stored as a cryptographic hash) is sent to your email address; setting a new password through the link both consumes the token and signs you in. Only verified addresses can request a reset |
| Sign-up and waitlist abuse prevention: refusing automated form submissions that would result in unsolicited verification emails to third parties or in false waitlist entries | Art. 6(1)(f) — legitimate interest in protecting our infrastructure, our outbound-email reputation, and third-party recipients from unsolicited messages, and in keeping our record of waitlist interest accurate | A proof-of-work captcha is required on the sign-up and waitlist forms. The accepted-challenge signature is stored briefly to prevent the same captcha solution being replayed. We also count recent waitlist entries from the same IP address and refuse further entries above a limit |
| Billing, invoicing, tax and accounting compliance | Art. 6(1)(b) and Art. 6(1)(c) — legal obligation | Paddle handles end-customer billing as MoR; we hold Paddle's monthly statements |
| Security: abuse detection, rate limiting, fraud prevention, incident response, security audit logs | Art. 6(1)(f) — legitimate interest in protecting the Service, our users, and our infrastructure | Feature-specific operational logs are described in your Service's Privacy Supplement |
| Data portability and access: providing a self-service export of your data (in fulfilment of your Art. 20 and Art. 15 rights), and rate-limiting that export to prevent abuse and accidental load | Art. 6(1)(b) — the export delivers data you provided under your service contract; Art. 6(1)(f) — legitimate interest for the rate-limit timestamp | The export is an exercise of your existing rights against already-lawful processing, not a separate processing activity. We retain only the timestamp of your most recent export to enforce the limit; see Section 8 |
| Customer support | Art. 6(1)(b) and Art. 6(1)(f) | |
| Service notifications (changes to Terms, Privacy Policy, security incidents, scheduled maintenance) | Art. 6(1)(b) and Art. 6(1)(c) | Cannot be opted out of while you have an active account |
| Product updates and marketing communications | Art. 6(1)(a) — consent | Opt-in only; opt-out at any time |
| Pre-launch waitlist contact | Art. 6(1)(a) — consent | You are added to the waitlist for the Service whose public site you signed up on; we contact you when the Service opens to general availability or to ask for early-access feedback. You can request removal at any time via privacy@byteimagination.com |
| Keeping a record of the emails we send you and what became of them | Art. 6(1)(b) — the messages themselves are part of providing the Service (address verification, password reset, billing notices, service notifications); Art. 6(1)(f) — legitimate interest in being able to answer "I never received it", and in protecting the deliverability of our mail for every customer | An address that permanently rejects our mail, or from which a spam report is received, stops receiving further mail from us until the problem is resolved. The record of what was sent, and of what our provider said about it, is what lets us tell that apart from a message we never sent |
| Compliance with legal obligations and defence of legal claims | Art. 6(1)(c) and Art. 6(1)(f) | |
| Proof of acceptance of these Terms, the Privacy Policy, the DPA, and per-Service Additional Terms | Art. 6(1)(b) — performance of contract; Art. 6(1)(f) — legitimate interest in demonstrating valid acceptance and defending against legal claims | The IP address attached to a legal acceptance is automatically cleared after 365 days; the acceptance record itself is kept as described in Section 6 |
4. Recipients and sub-processors
We share personal data only with the following categories of recipients:
- Paddle.com Market Ltd (UK) — Merchant of Record; processes payment, billing address, and tax data.
- DigitalOcean, LLC — hosting and infrastructure services.
- Resend, Inc. — transactional email delivery (account verification, password reset, billing notices, service notifications).
- rsync.net, Inc. (United States) — off-site storage of backup copies, which are encrypted on our server before they are sent, so rsync.net cannot read them.
- Public authorities — where required by law (court order, lawful request).
- The Account Owner and the other Authorised Users of the same Account — see your email address, your role and the date you joined. The Account Owner sees, for every API Key of the Account, when it was used and from which IP address and with which user agent, and, for every entry of the activity log of the Service, the IP address from which it was performed — the person who acted may be an Authorised User (Art. 6(1)(f) — the Customer's legitimate interest in the security of its Account). An invitation shows the name of the Account to the person invited; that name is the Account Owner's email address where the Account Owner has not given another one.
A current Sub-processor list with each provider's role and country of processing is published alongside this Policy. We notify you at least 30 days before adding or replacing a sub-processor for processor activities under the DPA.
5. International transfers
Personal data may be processed outside the European Economic Area where a sub-processor is located outside the EEA. Where this is the case, transfers are based on:
- An adequacy decision under Article 45 GDPR; or
- Standard Contractual Clauses (SCCs) under Article 46(2)(c) GDPR with supplementary measures as appropriate; or
- A derogation under Article 49 GDPR.
A copy of the SCCs in force for a given recipient is available on request to privacy@byteimagination.com.
6. Retention
| Data | Retention |
|---|---|
| Account data | For the lifetime of your account; deleted or irreversibly anonymised immediately on account closure, except for records retained on legal-basis grounds (billing — 5 years; legal acceptance records — see Section 8) and except for copies of your email address inside emails we had already sent you, which follow the outbound-message period below. A sign-up whose email address was never confirmed is deleted as described in the row "Sign-ups never confirmed" below |
| Billing records | 5 years from the end of the calendar year in which the transaction occurred (Polish accounting law) |
| Backup copies of the Service's data | We keep the last 7 daily, 4 weekly and 6 monthly backup copies, so a copy is deleted at the latest about seven months after it was made. A copy made before you closed your account therefore still contains your data until it is deleted. We use backups only to restore the Service after a failure |
| Billing linkage identifiers (references to your record at our payment processor) | For the lifetime of your subscription; deleted when your account is closed |
| API key hashes | Until you delete the key or close the account |
| API key labels (the human-readable name you assign) | Until you delete the key or close the account; revoked keys keep their label as part of the audit history. The record of which user created the key is kept with the key; after that user leaves the Account it no longer identifies them, because their user account is anonymised |
| API key revocation timestamps | For the lifetime of your account; preserved as part of the key's audit history |
| API request/response logs (Logbook) | 30 days, then deleted |
| API request/response markers and trace ids in application logs | 90 days |
| Feature-specific operational logs | As set out in your Service's Privacy Supplement |
| Per-API-key usage records (timestamp, IP, user agent) | 365 days from the time of each call, then the record is automatically deleted (the API key itself is preserved) |
| Data export request timestamp (the time of your most recent data export, kept to rate-limit exports under Art. 6(1)(f)) | One most-recent timestamp per user and one per Account, for as long as the user account or the Account exists; deleted on closure |
| Legal acceptance records | For the lifetime of your user account, and, after your user account is closed, until the end of the calendar year in which six years have passed since that closure, or longer if a specific claim is pending or threatened; then deleted automatically. See the note in Section 8 for the reason. The IP address attached to each acceptance is automatically cleared after 365 days. Acceptances given at a sign-up whose email address was never confirmed are not kept for this period: they are deleted together with that sign-up, as described in the row "Sign-ups never confirmed" below |
| Invitation data | 14 days from the issue of the invitation, or 7 days after it was used, whichever comes first. The invitation email itself is an outbound message record and follows that period below, including if you never accept it |
| Membership data | For as long as you are an Authorised User. When you leave the Account or are removed from it, your user account is anonymised as described for account closure |
| Actor identifiers in the activity log of the Service | As part of the Customer's data, for the lifetime of the Account. After you leave, the identifier no longer points to your identity on our side |
| Invoice-numbering idempotency keys | 24 hours, then automatically deleted |
| Submission-deduplication records (where your Service uses this feature) | As set out in your Service's Privacy Supplement |
| Email-address verification tokens | 24 hours, then automatically deleted whether or not the link was used; a new token is issued on each sign-up attempt |
| Sign-ups never confirmed | If the email address given at sign-up is not confirmed within 30 days, the account is deleted automatically within a day after the 30 days have passed, or, if a confirmation link we sent for it is still valid then, within a day after that link has expired: the email address, the hashed password, the name of the Account and the acceptance records given at that sign-up, including their IP address and user agent. They are not kept for the legal-acceptance period above, because a person who never confirmed the address never had access to the Service. Copies of the address inside the confirmation emails we sent follow the outbound-message period below. The address can be used for a new sign-up at any time. Exception: if the address permanently rejected our mail, or a spam report was received from it, the account — the email address, the hashed password, the name of the Account and those acceptance records — is kept for as long as that block is in effect, so that the address is not mailed again by a new sign-up (Art. 6(1)(f) — legitimate interest in not sending unwanted mail to that address and in protecting the deliverability of our mail); the IP address and user agent on its acceptance records are still cleared after 365 days. It is deleted as described above once the block is lifted |
| Password-reset tokens | 1 hour from issuance (after which the link no longer works), then a further 7-day forensic retention so we can answer support questions about why a link was rejected; deleted automatically thereafter. A new token is issued on each reset request |
| Sign-up abuse-prevention signatures | 20 minutes from acceptance, then automatically deleted |
| Outbound message records | 30 days from the moment the message was queued, and only once we have stopped trying to send it — if we are still trying after 30 days, the content is kept until we stop. Then the recipient address, the subject and the message text are deleted. What remains is the operational record — which template was sent, when, whether we managed to hand it over, our provider's identifier for the message, and a one-way cryptographic hash in place of the recipient address. That remainder is kept indefinitely, and is unlinked from your account when you close it. The hash cannot be reversed into an address, although we can check whether a particular address matches it — which is exactly what lets us act on an erasure request, and what lets a delivery failure arriving after the 30 days still be recognised as being about your own address rather than someone else's |
| Delivery-event records | 90 days from the moment we received the report, after which the report our email provider sent us — including the recipient address it contains — is deleted. Longer than the message itself because, once our own copy of a message is gone, the provider's report is the only remaining account of what happened to it. The record itself — its identifier, its type and its timestamps — is kept indefinitely with no personal data attached, because its identifier is what stops the same report being acted on twice |
| Email delivery block state | For as long as the block is in effect, and never longer than the lifetime of your account. Lifting the block deletes the cause and the date along with it, so the record exists only while it is true. If you close your account the cause is replaced with a closure marker, which carries nothing about you or about what your mail provider said |
| Support correspondence | 3 years from the date of the last message |
| Marketing opt-in records | Until you withdraw consent + 3 years for evidentiary purposes |
| Waitlist entries (email, IP, timestamp) | The IP address attached to a waitlist entry is automatically cleared after 365 days. The email and timestamp are kept until the Service opens to general availability and waitlist communications complete, until you request removal, or 24 months idle — whichever is earliest, after which the entry is automatically deleted |
7. Security
We apply technical and organisational measures appropriate to the risk, including:
- Encryption of data in transit using current industry-standard protocols;
- Encryption at rest of the database storage, by our hosting provider at the level of the storage volume; backup copies encrypted on our server before they leave it;
- API keys stored as cryptographic hashes, never in plaintext;
- Passwords stored using a salted, computationally expensive hash algorithm;
- Access control and least-privilege within the operations team;
- Audit logging of authenticated API access and administrative actions;
- Exclusion of single-use secret links from our server access logs: where a link we send you (such as an account-verification or password-reset link) or a payment-recovery link carries a one-time secret in its web address, our web server records only the path of the request and never the part of the address that carries the secret, so the secret itself is never written to those logs;
- Sub-processor due diligence and contractual safeguards.
No system is fully secure. If you believe your account has been compromised, contact privacy@byteimagination.com immediately.
8. Your rights
Subject to the conditions of GDPR you have the right to:
- access your personal data (Art. 15);
- rectify inaccurate or incomplete data (Art. 16);
- erasure ("right to be forgotten") (Art. 17);
- restriction of processing (Art. 18);
- data portability (Art. 20);
- object to processing based on legitimate interest (Art. 21);
- withdraw consent at any time, without affecting the lawfulness of processing before withdrawal (Art. 7(3));
- lodge a complaint with a supervisory authority. The Polish authority is the Prezes Urzędu Ochrony Danych Osobowych, ul. Stawki 2, 00-193 Warszawa, https://uodo.gov.pl. You may also lodge a complaint with the supervisory authority in your country of residence or work.
To exercise any right, contact privacy@byteimagination.com. We respond within one month, extendable by two further months for complex requests under Art. 12(3) GDPR.
Which rights you exercise with us, and which with the Account Owner. For your own account data (email address, role, sign-in, acceptance records) you exercise your rights directly with us. For data that the Customer entered into the Service — for example items in the Customer's activity log — we act as the Customer's processor and refer you to the Account Owner.
Self-service data export. You can exercise your rights of access and data portability (Art. 15 and Art. 20) at any time without contacting us: sign in and use Export your data in your account. Every user receives a downloadable archive of machine-readable JSON files with their own account details, role, legal acceptance records, the API keys they created (without the keys themselves) and the actions the Service attributes to them, as its Exportable Data page lists — when, what kind of action, and which item, without the content of the Customer's data. The Account Owner's archive also contains the data of the Account: the data created in the Service, the full activity history — including a record of operations on items since deleted — and the list of the Account's users. The categories and formats for your Service are listed on the Exportable Data page published alongside this Policy. The Account Owner's archive also contains the API usage records of the Account, with their IP addresses and user agents, and the IP addresses of the entries of the activity log. Other IP addresses and user agents we hold about you, such as those attached to your acceptances, are not in the self-service archive; you can request them at privacy@byteimagination.com and we provide them as Art. 15 GDPR requires, for as long as we hold them. To prevent abuse, the self-service export can be used once every 30 days; this does not limit your right to request your data from us at any time, which we fulfil within one month as described above. The Account Owner's export of Customer Data on request is provided without undue delay and within thirty days (Section 14 of the Terms of Service).
Note on legal acceptance records: the right to erasure under Art. 17 does not extend to legal acceptance records (timestamp, acceptance method, document version, and locale of each version you accepted) to the extent those records are necessary for the establishment, exercise, or defence of legal claims (Art. 17(3)(e) GDPR). An acceptance the Account Owner gave for the Customer stays linked to the Account's billing records after closure. We keep it until the end of the calendar year in which six years have passed since the closure, or longer if a specific claim is pending or threatened. The reason is the limitation period of claims under the contract: it is generally six years and ends on the last day of a calendar year (art. 118 of the Polish Civil Code), and it runs separately for each claim from the day that claim became due (art. 120 § 1). We cannot know in advance on which day a possible claim would fall due, so we use the closure of the user account as one fixed reference date for all records; for most claims it is later than the day the claim fell due. We use one period for every Customer because we cannot reliably tell at closure which category a future claim would belong to, and the longer, six-year period applies to claims of consumers. Records of an Authorised User's acceptance are kept, in a form that no longer shows their e-mail address, for as long as is needed to show on what terms that person used the Account — until the end of the calendar year in which six years have passed since the user account was closed (Art. 6(1)(f); limitation of claims under the contract, art. 118 KC). The IP address attached to each acceptance is cleared automatically after 365 days.
9. Cookies
The Service uses cookies as described in our Cookie Policy.
10. Automated decision-making
We do not make automated decisions that produce legal effects concerning you or that similarly significantly affect you within the meaning of Article 22 GDPR.
Some processing described in Section 3 (security, abuse detection, rate limiting) is automated by nature but does not meet the Article 22 threshold: it is a standard feature of API services and does not determine rights, contract terms, or access in a way that cannot be remedied through human review. If you believe your account has been incorrectly blocked or limited, contact privacy@byteimagination.com and a human will review the decision.
If we introduce processing that meets the Article 22 threshold in the future, we will update this section and notify you in accordance with Section 11.
11. Changes to this Policy
We may update this Policy from time to time. Material changes are notified by email at least 30 days before the effective date. The effective date is shown at the top of this document. We retain prior versions of this Policy; if you want an earlier version, or the version in force when you accepted it, request it at privacy@byteimagination.com and we will send it to you.
12. Contact
Privacy questions and requests: privacy@byteimagination.com.