This Cookie Policy explains how Isentró Kft. ("RunHarvester", "we", "us", or "our") uses cookies and other technologies that store information on, or access information from, a browser, device, application, or similar terminal equipment.
This Policy is intentionally broader than browser cookies. It also covers local storage, session storage, pixels, tags, scripts, software development kits, device identifiers, link decoration, and comparable storage or access technologies (together, "Technologies").
The Privacy Policy explains the wider processing of Personal Data. This Cookie Policy explains only the Technologies used on RunHarvester-controlled online services and the choices available to users.
Cookie choices at a glance
- Technologies that are strictly necessary to provide a service you request, secure an Account, transmit a communication, record your privacy choice, or complete a requested checkout may operate without optional consent where law permits.
- Optional analytics, advertising, and similar Technologies are disabled until a valid choice permits them in jurisdictions where prior consent is required.
- You can select Reject optional, Accept all, or Customize through the cookie preference interface where it is displayed.
- Rejecting optional Technologies must not prevent access to ordinary public website content or core paid functionality, although a feature that depends on an optional third-party integration may not work.
- You can withdraw consent or change a preference later. Withdrawal does not make earlier lawful processing unlawful.
- We do not intentionally place API keys, passwords, proxy credentials, authorization headers, complete collection results, private browser-session content, or payment-card numbers into analytics or advertising events.
- The current cookie preference centre is the authoritative live inventory for exact identifiers and third-party vendors enabled in a particular environment. Optional Technologies must not be enabled unless they are correctly categorized and disclosed there.
1. Who we are
RunHarvester is operated by:
Isentró Kft.
Hungarian company registration number: 01-09-444499
Hungarian tax number: 32822933-1-42
Registered office: 1082 Budapest, Corvin sétány 6, 8th floor, unit 4, Hungary
Privacy contact: [email protected]
For Technologies used on RunHarvester-controlled websites and applications, Isentró Kft. is normally the controller of the associated Personal Data unless a notice identifies another party.
2. Scope
This Cookie Policy applies to Technologies used when you visit or interact with:
- runharvester.com and its public pages;
- docs.runharvester.com;
- the RunHarvester dashboard, Account, authentication, billing, support, and preference interfaces;
- another RunHarvester-controlled web page or subdomain that links to this Policy; and
- an embedded RunHarvester-controlled form or component where this Policy is presented.
This Policy does not govern:
- Technologies used on a Target selected by a Customer;
- a Customer's own website or application;
- a third-party website opened in a separate browser context;
- a Customer-selected webhook, integration, proxy, storage service, or AI provider;
- the later use of data by a third party acting as an independent controller; or
- device storage created inside a Customer-instructed browser workflow on a Target, which is treated as Customer Content under the Privacy Policy and DPA rather than as a RunHarvester website cookie.
A third party may use its own Technologies when you deliberately open or use its service, such as a payment checkout or identity-provider page. Its own notice governs that independent use.
3. What Technologies are covered
3.1 Cookies
Cookies are small text values that a website or service stores in a browser. A cookie can be:
- session-based, meaning it generally expires when the browser session ends;
- persistent, meaning it remains until its expiry date or deletion;
- first-party, meaning it is associated with a RunHarvester-controlled domain; or
- third-party, meaning it is associated with another provider's domain or service.
3.2 Local and session storage
Web storage allows a website or application to store values in a browser. Session storage generally lasts for the relevant tab or browser session. Local storage may remain until it is deleted by the service, the user, the browser, or a configured retention process and does not necessarily have a built-in expiry date.
3.3 Pixels and tags
A pixel, tag, or similar resource can record that a page, message, or feature was loaded or used. It may transmit information such as time, page, device, IP address, referrer, and campaign parameters.
3.4 Scripts, SDKs, and libraries
Scripts and software libraries can provide authentication, payment, security, consent management, analytics, support, documentation search, or user-interface functionality. They may read or write browser storage or transmit data without creating a conventional cookie.
3.5 Device and network techniques
Some security and fraud-prevention tools use device, browser, network, or interaction signals to distinguish legitimate use from abuse. These can include IP address, browser configuration, timing, request patterns, and device characteristics. We do not use a label such as "cookie-free" to avoid disclosing a technology that still stores or accesses device information.
3.6 Link decoration
Campaign, referral, language, authentication-state, or navigation parameters may be added to a link. These parameters can be read when the destination opens and may then be stored or associated with a session.
4. Legal framework and bases
Different rules can apply depending on location and the purpose of a Technology.
4.1 Storage and access rules
Where applicable electronic-communications law requires consent before information is stored on or accessed from a device, we request consent unless a statutory exception applies. A Technology is not treated as exempt merely because it is useful to us.
Common exceptions can include Technologies used solely:
- to transmit a communication over a network;
- where strictly necessary to provide an online service explicitly requested by the user;
- for limited statistical purposes where local law permits that exception and all statutory safeguards are met;
- to adapt appearance or functionality to a user preference where local law permits that exception and all statutory safeguards are met; or
- for another narrow statutory purpose.
An exception is applied to the specific purpose, not automatically to the entire vendor or script. If one Technology serves multiple purposes, each purpose must be assessed and any non-exempt purpose remains subject to the required choice.
4.2 Data-protection bases
Where a Technology processes Personal Data, we also identify a lawful basis under applicable data-protection law. Depending on the purpose, this may be:
- performance of a contract or steps requested before entering into a contract;
- compliance with a legal obligation;
- legitimate interests in authentication, security, fraud prevention, service reliability, preference management, or limited measurement, balanced against user rights; or
- consent for optional analytics, marketing, or another purpose where consent is required or chosen as the basis.
Consent under device-storage law and a lawful basis under data-protection law are related but separate requirements. Accepting these Terms of Service does not itself constitute cookie consent.
4.3 Conservative default
Because RunHarvester serves users in multiple jurisdictions, we ordinarily use a conservative configuration: non-essential analytics and marketing Technologies are not activated before consent where prior consent may be required. We rely on a no-consent statistical or appearance exception only where the applicable law clearly permits it and the implementation satisfies its conditions, including clear information and a simple, free means to object.
5. Why we use Technologies
We may use Technologies for the following purposes:
- Network communication and routing - transmitting requests, routing a session, balancing load, and maintaining continuity.
- Authentication and Account security - signing in, maintaining a secure session, supporting multi-factor authentication, preventing cross-site request forgery, and detecting suspicious access.
- Consent and privacy choices - recording categories accepted or rejected, policy version, timestamp, region, and withdrawal.
- Requested functionality and preferences - language, theme, display, navigation, documentation state, accessibility, and other user-selected settings.
- Billing and checkout - preserving a requested checkout flow, detecting payment fraud, and returning to the correct Account after a payment-provider interaction.
- Reliability and diagnostics - identifying errors, measuring performance, correlating a page failure, and maintaining service quality.
- Product and website analytics - understanding aggregated use of pages and features, acquisition sources, and general usage patterns.
- Communications and campaign measurement - understanding whether an optional campaign or product communication led to a visit or conversion.
- Embedded and third-party functionality - enabling an identity provider, payment flow, support tool, CAPTCHA, documentation search, or other feature selected by the user.
- Legal and abuse prevention - retaining evidence of a privacy choice, preventing repeated misuse, and investigating attacks or fraudulent activity.
6. Live inventory and policy accuracy
6.1 Authoritative live register
Technology names can be generated, versioned, or changed by authentication, infrastructure, consent, payment, monitoring, and other providers. The Cookie Settings or equivalent preference centre available on the relevant RunHarvester page is the authoritative live register for:
- identifier or Technology name;
- provider;
- domain or environment;
- category;
- purpose;
- whether it is first-party or third-party;
- typical or maximum lifetime; and
- whether it is active under the user's current choice.
The live register forms part of this Cookie Policy.
6.2 Publication condition
A new optional Technology must not be enabled in production until it has been:
- inventoried;
- assigned an accurate purpose and category;
- blocked before consent where required;
- added to the preference centre;
- reviewed for data minimization, retention, recipients, and international transfers; and
- tested to confirm that rejection and withdrawal are respected.
6.3 Conflict or missing entry
If a specific live-register entry and a general description in this Policy differ, the more specific current entry controls for the identifier concerned, but it cannot reduce a user's mandatory rights. If an optional Technology is detected but not disclosed in the live register, it should be treated as disabled pending review rather than treated as silently authorized.
6.4 Environment differences
Not every Technology is used on every domain, page, browser, region, Account, or feature. A dashboard may require authentication storage that a public documentation page does not use. A payment or identity-provider Technology may appear only after the user starts that flow.
7. Strictly necessary Technologies
Strictly necessary Technologies support a service the user explicitly requests or protect that service in a manner necessary and proportionate to its delivery. They can include:
- authentication and secure-session identifiers;
- anti-CSRF values, state parameters, and nonces;
- multi-factor authentication and trusted-device preferences requested by the user;
- load-balancing and session-routing identifiers;
- consent-choice and privacy-preference records;
- checkout state and return-path information;
- security, fraud-prevention, and abuse-prevention controls;
- password-reset, email-verification, and account-recovery state;
- rate-limit or request-integrity controls where device storage is necessary;
- a short-lived identifier needed to complete an identity-provider flow; and
- a Technology needed to comply with a legal security duty where there is no reasonable less intrusive method.
Strictly necessary Technologies are not used for unrelated advertising or cross-site profiling. Disabling them through browser controls may prevent sign-in, security checks, Account administration, billing, or another requested feature from functioning.
8. Preference and functional Technologies
Preference Technologies can remember choices such as:
- dark, light, or system appearance;
- language, locale, time zone, and display format;
- navigation, documentation, or panel state;
- accessibility or interface settings;
- a selected workspace or recently used non-sensitive setting; and
- whether a non-essential interface element has been dismissed.
A preference may be strictly necessary when the user specifically requests it and the Technology is the reasonable means to provide that choice. In other contexts it may be optional. The preference centre identifies the applicable treatment.
We do not intentionally store API secrets, target credentials, private result content, or sensitive Customer Content in a general preference value.
9. Analytics and performance Technologies
Analytics and performance Technologies may help us understand:
- page and feature use;
- navigation paths and general interaction events;
- approximate region, language, browser, operating system, and device class;
- referral or campaign source;
- response time, page load, client-side error, and failure rate;
- aggregate conversion or onboarding completion; and
- whether a design or documentation change improves usability.
Where prior consent is required, these Technologies remain disabled until consent. Where a limited statistical exception is available, we rely on it only if the implementation is solely for service statistics, does not enable cross-service tracking or advertising, uses appropriate minimization, and offers the required simple means to object.
Analytics events must not intentionally contain:
- full API keys or proxy credentials;
- passwords, private keys, authorization headers, cookies, or recovery codes;
- payment-card numbers or card verification codes;
- complete HTML, screenshots, extracted datasets, or private browser content;
- full target credentials or authenticated session values;
- health, biometric, or other Sensitive Data; or
- unrestricted support-message or prompt content.
We may use server-side logs and operational metrics that do not store or access information on a user's device. Those records are described in the Privacy Policy and are not automatically governed by cookie consent merely because they concern an online request.
10. Marketing and campaign Technologies
Marketing Technologies may be used, where enabled and lawfully authorized, to:
- attribute a visit or signup to a campaign, partner, or referral;
- measure the effectiveness of a product announcement or advertisement;
- avoid repeatedly showing the same campaign;
- create or use an advertising audience; or
- support cross-site or cross-context advertising.
RunHarvester does not activate marketing Technologies before valid consent where consent is required. We do not use Customer Content or people appearing in collected Target pages to build advertising profiles.
Rejecting marketing Technologies does not stop strictly necessary service notices, security messages, invoices, or communications otherwise permitted by law. It can reduce our ability to measure campaign effectiveness or tailor optional promotions.
11. Feature-led and third-party Technologies
11.1 Identity providers
If a user chooses a supported third-party sign-in method, such as Google or Telegram authentication, the relevant provider may use its own Technologies to authenticate the user, prevent fraud, and complete the requested connection. A short-lived state or nonce may be strictly necessary on RunHarvester's side. Technologies already present on the provider's own domain are governed by the provider's notice.
RunHarvester does not require a user to consent to unrelated marketing Technologies merely to use an identity-provider option.
11.2 Payment providers
When a user starts a checkout, a payment provider may use Technologies for payment authentication, fraud prevention, transaction continuity, and legal compliance. These may be strictly necessary for the requested transaction. The payment provider can also act as an independent controller for its own regulated activities.
11.3 CAPTCHA and abuse prevention
A public form, login, recovery flow, or high-risk request may use a CAPTCHA, challenge, or device-risk service to prevent automated abuse. Such a service may process IP address, browser characteristics, timing, interaction signals, and challenge state. We use it only where reasonably necessary and proportionate to protect the requested service or where the user has made the applicable choice.
This section concerns protection of RunHarvester-controlled pages. A challenge encountered on a Customer-selected Target during a browser workflow is Customer Content and is governed by the Terms, Privacy Policy, and DPA.
11.4 Error monitoring and support
An error-monitoring or support provider may receive limited page, browser, error, and diagnostic information. We configure such tools to minimize sensitive content and to avoid sending secrets. A support widget or session-replay function, if ever enabled, must be separately inventoried, masked, and categorized; it is not treated as automatically necessary merely because it is useful for support.
11.5 Embedded content
An embedded video, map, social element, external documentation search, or similar feature may allow another provider to use Technologies. Optional embedded content is blocked, isolated, or activated only after the relevant choice where required. Opening a direct link to a third-party site is governed by that site's own notice.
12. Technology register by function
The following table describes the classes of Technologies that may appear. It does not replace the exact live register in Cookie Settings.
| Technology class | Typical provider | Category | Purpose | Typical duration approach |
|---|---|---|---|---|
| Consent and policy record | RunHarvester or consent-management provider | Strictly necessary | Store accepted/rejected categories, policy version, timestamp, region, and withdrawal | Commonly up to approximately 6 months before a renewed choice; a minimal server-side compliance record may be retained longer where lawful |
| Authentication session | RunHarvester or authentication provider | Strictly necessary | Maintain a secure signed-in session and organization context | Session or the login period selected or shown to the user; ends earlier on logout, revocation, or security action |
| CSRF, OAuth state, nonce, and return path | RunHarvester or selected identity provider | Strictly necessary | Prevent request forgery and complete a user-requested authentication flow | Minutes to the end of the relevant session or flow |
| Load balancing and routing | RunHarvester infrastructure provider | Strictly necessary | Route communications to an appropriate service instance | Usually session-based or short-lived |
| Multi-factor or trusted-device state | RunHarvester or authentication provider | Strictly necessary when requested | Support account security and a user-selected trusted-device period | Until the displayed period ends, the user revokes it, or a security event requires reset |
| Account recovery and verification state | RunHarvester or authentication/email provider | Strictly necessary | Complete verification, password reset, or recovery | Short-lived; generally minutes or hours and invalidated after use |
| Checkout and transaction state | RunHarvester or payment provider | Strictly necessary for requested checkout | Maintain transaction continuity, authenticate payment, and prevent fraud | Session or provider-defined period required for transaction, fraud, and legal records |
| Security and anti-abuse signals | RunHarvester or security provider | Strictly necessary where proportionate | Detect account takeover, automated abuse, fraud, and malicious traffic | Risk-based; device values are kept no longer than needed for the security purpose |
| Theme, language, locale, and interface preference | RunHarvester | Functional or exempt preference where law permits | Remember a user-selected appearance or interface setting | Session to approximately 12 months, or until changed or cleared |
| Documentation and navigation state | RunHarvester or documentation provider | Functional | Remember navigation, dismissed notices, or documentation state | Session to approximately 12 months depending on the setting |
| Performance and error measurement | RunHarvester or monitoring provider | Analytics unless strictly necessary and exempt | Measure page reliability, latency, and client-side errors | Session to no more than the duration shown in Cookie Settings; optional identifiers ordinarily no longer than 13 months |
| Product and website analytics | RunHarvester or analytics provider | Analytics | Understand aggregate page and feature use | Optional identifiers ordinarily no longer than 13 months and subject to consent renewal or objection rules |
| Referral and campaign attribution | RunHarvester or analytics/marketing provider | Analytics or marketing | Attribute visits, signups, or purchases to a campaign or partner | Commonly session to 90 days unless a shorter or different period is shown |
| Advertising or audience identifiers | Advertising provider, if enabled | Marketing | Advertising, audience, frequency, or cross-context measurement | Only with required consent; duration shown in Cookie Settings and ordinarily not longer than necessary |
| Support or embedded-feature state | Support or content provider, if enabled | Functional, analytics, or marketing depending on purpose | Enable a feature deliberately selected by the user | Session or provider-defined period disclosed in Cookie Settings |
A duration in this table is a category-level description, not an extension of a shorter lifetime shown in the live register.
13. Information processed through Technologies
Depending on the Technology and choice, we may process:
- a random or pseudonymous identifier;
- consent categories, policy version, timestamp, and region;
- Account or session state;
- IP address and approximate location derived from it;
- browser type and version, operating system, language, time zone, screen or device class;
- page URL, referrer, navigation path, interaction, and timestamp;
- campaign, partner, or referral parameters;
- login, checkout, authentication, or security outcome;
- performance, latency, error code, and diagnostic context;
- fraud, abuse, or device-risk signals; and
- a preference selected by the user.
Where a value can be linked to an Account or identifiable person, we treat it as Personal Data as required by law. A pseudonymous identifier is not necessarily anonymous.
14. Recipients and international transfers
14.1 Service providers
Technology-related data may be processed by providers that support:
- hosting, content delivery, networking, and security;
- consent management;
- authentication and identity;
- payment and fraud prevention;
- analytics and performance monitoring;
- error reporting and support;
- email and communications; or
- an embedded feature selected by the user.
The live register identifies active third parties. Our Privacy Policy and, where relevant, Subprocessor List provide additional information about roles and transfers.
14.2 Independent controllers
A payment provider, identity provider, advertising provider, or other third party may determine some purposes independently and act as a separate controller. Its own privacy notice applies to those purposes.
14.3 Transfers
A provider may process data outside Hungary, the EEA, the United Kingdom, or the user's country. Where RunHarvester is responsible for a restricted transfer, we use an available lawful mechanism such as an adequacy decision, Standard Contractual Clauses, the UK Addendum or IDTA, and supplementary safeguards as required.
The choice to open a third-party site or use a Customer-selected destination can result in processing governed by that third party rather than by RunHarvester.
15. Consent and preference management
15.1 Choice design
Where consent is required, the interface is designed to provide:
- clear and sufficiently specific information;
- separate categories for materially different optional purposes;
- no pre-enabled optional categories;
- an Accept all option;
- a comparably accessible Reject optional option; and
- a Customize option.
Consent is not inferred solely from silence, continued browsing, use of the Service, acceptance of the Terms, or a pre-ticked setting.
15.2 Recording consent
We may record:
- categories accepted or rejected;
- date and time;
- policy or vendor-list version;
- approximate region or legal configuration;
- consent mechanism version;
- a pseudonymous browser identifier; and
- later withdrawal or change.
This record helps us apply the choice and demonstrate compliance. It is itself normally strictly necessary.
15.3 Withdrawal and change
You can reopen Cookie Settings through the footer, preference control, Account setting, or equivalent link on a relevant page. A new choice applies prospectively. Technologies already stored may need to be deleted by the preference tool or browser, and data already lawfully processed may remain under applicable retention rules.
15.4 Renewal
As a general operational guideline for optional Technologies, we aim to request a fresh choice after approximately six months, unless the applicable law, the user's expectations, the nature of the Technology, or a documented risk assessment supports a different period. A material new purpose or provider requires a fresh choice sooner where consent is required.
We may request a renewed choice when:
- the applicable legal period ends;
- purposes or vendors materially change;
- the consent record is missing or invalid;
- the browser storage was cleared;
- a different browser, device, or domain is used; or
- law or regulatory guidance requires a new request.
We do not repeatedly request consent merely to pressure a user who rejected optional Technologies.
15.5 Signed-in and signed-out choices
A cookie choice is often specific to a browser and device. Where technically and legally appropriate, a signed-in Account preference may help synchronize a choice, but a synchronized preference will not be used to turn on optional device storage on another device without the required local consent.
16. Browser controls, signals, and other choices
16.1 Browser controls
Most browsers allow users to view, delete, block, or limit cookies and site data. Blocking all storage can prevent sign-in, consent recording, security, billing, or preferences from working.
Local storage and session storage may need to be cleared through browser site-data controls rather than a traditional cookie list.
16.2 Global Privacy Control
Where Applicable Law requires recognition of Global Privacy Control or another legally valid opt-out preference signal, RunHarvester treats a recognized signal as an opt-out for the relevant sale, sharing, targeted-advertising, or similar processing associated with that browser or device.
A privacy-control signal does not itself provide affirmative consent for an optional Technology. It may not replace a granular cookie choice where local law requires one.
16.3 Do Not Track
There is no universally binding interpretation of the browser "Do Not Track" signal. We do not treat an unstandardized signal as affirmative consent. Where the signal is legally recognized or incorporated into a supported preference standard, we respond as required.
16.4 Email controls
An email can contain a measurement pixel or decorated link where lawfully enabled. You can disable image loading in the email client and unsubscribe from optional marketing. Service, security, billing, and legal messages may still be sent where necessary.
16.5 Mobile and application controls
If a RunHarvester mobile application or SDK is introduced, operating-system controls and an in-app privacy interface may provide additional choices. The live policy and relevant store notice will identify those Technologies before use.
17. Retention
17.1 Device retention
Each identifier should remain on the device only for the period reasonably necessary for its purpose and the period shown in Cookie Settings. A session Technology generally ends with the session, but browser behavior can preserve or restore a session. Local storage may remain until actively cleared; where we control it, we apply deletion or invalidation appropriate to the purpose.
17.2 Optional identifiers
Optional analytics and marketing identifiers are configured for a limited duration. Unless a more specific live entry or legal requirement applies, we aim not to use an optional browser identifier for longer than 13 months without renewal, replacement, or reassessment. A shorter period shown in Cookie Settings controls.
17.3 Consent evidence
A device consent record may remain for up to approximately six months or the applicable renewal period. A minimal server-side record may be kept longer where reasonably necessary to demonstrate compliance, resolve a complaint, or honor a continuing objection.
17.4 Security records
Security, fraud, and abuse records can be retained longer than a browser value because patterns may need to be investigated and legal claims preserved. The Privacy Policy describes that controller-side retention.
17.5 Deletion limits
Clearing a browser Technology does not automatically delete server-side Account, billing, security, or legal records, and deletion of a server-side record does not necessarily remove a third party's independent copy. Privacy rights can be exercised as explained in the Privacy Policy.
18. APIs, SDK clients, and non-browser use
RunHarvester APIs normally use API keys, signatures, headers, request identifiers, or other programmatic authentication rather than browser cookies. API requests still create server-side usage, security, billing, and operational logs described in the Privacy Policy.
A developer can embed an SDK, documentation component, authentication flow, or dashboard in an environment that uses device storage. The developer or Customer is responsible for its own interface, consent mechanism, and disclosures where it controls that deployment.
The Customer must not copy a RunHarvester website cookie into an API client as a substitute for a supported authentication method.
19. Security and data minimization
We apply controls intended to reduce misuse of Technology data, including category review, consent gating, least-privilege provider access, retention limits, secure transmission, and restrictions on sensitive event content.
Users and Customers must not place secrets or Sensitive Data in:
- URLs or campaign parameters;
- analytics event names or properties;
- browser-readable storage unless the product specifically requires and protects it;
- support-widget fields;
- public documentation search; or
- client-side code or repositories.
No browser storage or online service can be guaranteed absolutely secure. Users should log out of shared devices, protect browser profiles, and clear site data where appropriate.
20. Children
RunHarvester is a business-oriented service and is not directed to children. A person under 18 must not create an Account. We do not knowingly use optional advertising Technologies to profile children through RunHarvester-controlled pages.
If you believe a child used a RunHarvester-controlled page in a way that resulted in unauthorized device or Account data, contact us so that we can investigate and take action required by law.
21. Changes to this Cookie Policy
We may update this Policy when Technologies, providers, domains, features, laws, or regulatory guidance change. The updated version will show a new date.
A material new optional purpose or provider will be reflected in Cookie Settings and, where required, will not be enabled until a new valid choice is obtained. A policy update alone does not convert a previous rejection into consent.
Historical versions may be made available on request where reasonably required to understand a prior choice.
22. Contact
Questions about Technologies, consent, withdrawal, a provider, or privacy rights may be sent to:
Isentró Kft. / RunHarvester
1082 Budapest, Corvin sétány 6, 8th floor, unit 4, Hungary
[email protected]
Use the subject Cookie or Privacy Question. Do not include passwords, full API keys, authorization headers, private keys, payment-card data, or unnecessary Sensitive Data.