Guidelines for Legal Requests
Last updated: [TBD] · This is a working draft pending legal review.
1. Overview
Coded B.V. ("Coded", "we", "us", "our"), a private limited company (besloten vennootschap) registered in the Netherlands and part of the Coded Holding B.V. group, operates an international commerce platform. On the platform, sellers ("merchants") run one or more branded online shops and other projects (together, "projects") under an account container we call an "Organization", with a curated catalog, built-in payments processed through Stripe and Mollie, and built-in fulfilment.
These Guidelines for Legal Requests ("Guidelines") explain how Coded responds when a government, law-enforcement, regulatory, or judicial authority ("authorities") seeks data or other action relating to a user, merchant, Organization, project, or end customer. They describe who may make a request, the legal process we require, how we review and narrow requests, what categories of data may exist, when and how we notify affected users, how we handle emergencies, and how we treat cross-border requests.
Coded operates globally. The Netherlands is our place of registration and initial launch market, but our users, merchants, and their customers are located in many countries. These Guidelines therefore set a single, consistent standard that we apply to requests from any jurisdiction, layered on top of the mandatory law that applies to a given request.
These Guidelines are informational. They do not create rights for any third party, do not constitute a waiver of any legal protection or objection available to Coded or to our users, and do not constitute legal advice. They form part of, and should be read together with, our Terms of Service and Privacy Policy. Capitalized terms not defined here have the meaning given in those documents.
2. Who May Submit a Request
We accept legal requests only from authorities acting within their lawful jurisdiction and competence — for example, law-enforcement agencies, prosecutors, courts, and regulators empowered to compel the production of information. A request must come from an official government source, be made by an identifiable official acting in their official capacity, and be submitted on official letterhead or from an official government email domain, or otherwise be verifiable as genuine.
We may decline or hold any request while we verify its authenticity, including by contacting the issuing authority through independently confirmed channels. We do not act on requests that we cannot authenticate, that are submitted by private parties under the guise of legal process, or that are facially defective.
Private parties (including in civil litigation, IP disputes, or commercial disputes) should not use this channel to obtain another user's data. Civil discovery, subpoenas in private litigation, and similar demands are routed to counsel and assessed separately; we will generally require the requesting party to seek the information directly from the user or through a competent court, and we will object to overbroad or improper civil demands.
3. Coded's Role and Where Data Lives
Coded provides infrastructure that merchants use to run their own projects. In many cases the merchant — not Coded — is the party that determines what personal data is collected from end customers and why. For end-customer personal data processed on a merchant's behalf, Coded generally acts as a processor and the merchant as the controller; for our own account, billing, and platform-operations data, Coded acts as a controller. Authorities seeking data that a merchant controls should, where appropriate, direct their request to that merchant.
Where Coded is the appropriate recipient, we host platform data on infrastructure located in the European Union (Frankfurt, Germany). EU hosting is a deliberate design choice for security and data protection. The location of our data and our place of establishment are relevant to which legal process is valid and to which cross-border cooperation mechanisms apply (see Section 8).
4. Required Legal Process
The legal instrument we require depends on the type of data sought and the law that binds the request. As a baseline, and subject to the mandatory law of the relevant jurisdiction:
- Basic subscriber / account information (for example, the name, email address, and Organization associated with an account) requires, at minimum, a valid subpoena, lawful production order, or equivalent compulsory legal process.
- Non-content records (for example, account metadata, certain logs, or transaction-level records that do not reveal communications content) require a court order or equivalent legal process appropriate to the sensitivity of the data.
- Content and sensitive personal data (for example, the contents of stored materials, or special categories of personal data) require a warrant, court order, or equivalent judicial authorization issued on a sufficient legal standard.
For requests governed by EU law and Netherlands law, Coded relies on a valid legal basis under the General Data Protection Regulation. Disclosure compelled by these Guidelines is made on the basis of Article 6(1)(c) GDPR (compliance with a legal obligation to which Coded is subject) or Article 6(1)(e) GDPR (performance of a task carried out in the public interest or in the exercise of official authority), as applicable. Where an authority relies on a restriction of data-subject rights or controller obligations, we expect it to identify the legislative measure that meets the conditions of Article 23 GDPR. A foreign authority's order does not, by itself, create a GDPR legal basis to disclose; an enforceable EU/Netherlands legal obligation, or a recognized international cooperation mechanism, must support the disclosure.
We will not treat informal requests, voluntary "preservation" letters, or correspondence that merely asserts authority as sufficient to compel content. We may, however, take limited preservation steps where the law permits (see Section 9).
5. How We Review and Narrow Requests
Every request is reviewed by our legal function before any data is disclosed. Our review includes whether:
- the request comes from an authority with jurisdiction over Coded or the data sought;
- the legal instrument matches the category of data sought (Section 4);
- the request is specific — it identifies particular accounts, projects, time periods, and data categories rather than seeking broad or speculative production;
- the request is proportionate to its stated purpose and not excessive; and
- compliance would conflict with the law of another jurisdiction, including Netherlands and EU law (a "conflict of laws" situation).
Where a request is overbroad, vague, or disproportionate, we will push back and ask the authority to narrow it, and we will produce only the minimum data within scope. Where a request is defective, unlawful, conflicts with binding law, or exceeds the authority's competence, we may object, seek modification, or challenge it through appropriate legal channels. We disclose only what we are legally required to disclose, in the narrowest form that satisfies the valid request.
6. Categories of Data That May Exist
The data potentially responsive to a request varies by account and is limited to what we actually hold. Depending on the account, the categories that may exist include:
- Account and Organization records — account holder name, email address, Organization name and identifiers, account status, and creation date.
- Billing and subscription records — subscription plan, invoices, and billing identifiers. Coded charges a 0% platform fee on merchant payment transactions; payment card data and the underlying payment flows are handled by our payment processors (Stripe and Mollie) under their own systems and policies, and requests for cardholder or payment-transaction data may need to be directed to those processors.
- Project and content data — project configuration and materials that a merchant has stored on the platform, where Coded holds them and is the appropriate party to produce them.
- Operational logs and metadata — limited technical and security logs retained for defined periods consistent with our Privacy Policy. Consistent with our privacy-by-design approach and cookieless analytics, we deliberately collect and retain less data than many platforms, and we do not maintain certain categories of tracking data at all.
We cannot produce data we do not have or no longer retain. We do not sell or share personal data, and these Guidelines do not change that: compelled disclosure to an authority under valid legal process is not a sale or a commercial sharing of data.
7. Notifying Affected Users
Our default policy is to notify a user, merchant, or Organization before disclosing their data in response to a legal request, so that they have an opportunity to seek to limit or challenge the request. We will provide a copy of the request, or its substance, where we are permitted to do so.
We will delay or withhold notice only where we are legally prohibited from notifying (for example, under a valid non-disclosure order or gag provision), or where we reasonably believe that notice would create a risk of harm to a person, endanger an investigation involving a risk of death or serious physical injury, risk harm to a child, or risk destruction of evidence. Where we are temporarily barred from notifying, we will provide notice after the prohibition lapses, where lawful and practicable.
Notice to the affected user does not necessarily delay our response to the authority beyond any period the law or the order requires.
8. International and Cross-Border Requests
Because Coded is established in the Netherlands and hosts platform data in the EU, requests from authorities outside the Netherlands and the EU generally must be channelled through a recognized international cooperation mechanism rather than served directly. Depending on the requesting country, this may include:
- a Mutual Legal Assistance Treaty (MLAT) request or a letter rogatory processed through the competent Netherlands authorities;
- an order issued or recognized under an applicable EU cross-border e-evidence framework or other instrument that is enforceable against a Netherlands-established provider; or
- another lawful basis that renders the request enforceable under Netherlands or EU law.
A direct order from a foreign authority that is not enforceable in the Netherlands, and that has not passed through an applicable cooperation mechanism, will generally not be a sufficient basis for us to disclose data — particularly where doing so would breach the GDPR or other binding EU/Netherlands law. Where a foreign order conflicts with EU or Netherlands law, we will treat it as a conflict of laws and will engage the requesting authority and, where appropriate, the competent local authorities to resolve it lawfully. Nothing in this Section prevents an authority of a user's own jurisdiction from relying on mandatory local law that applies to that user.
9. Emergency Disclosure
In a genuine emergency — where we believe in good faith that disclosure without delay is necessary to prevent an imminent risk of death or serious physical injury to a person — we may provide the limited information reasonably necessary to address that emergency, to the extent the law permits, even before formal legal process is completed.
An emergency request must come from an identifiable, verifiable authority, describe the nature of the emergency and the imminent risk, and explain why the requested information is needed to address it and why the situation cannot await ordinary process. We assess each emergency request on its own facts and disclose only the minimum necessary. We may decline an emergency request that does not credibly establish an imminent risk. We may also take lawful preservation steps to safeguard relevant data while proper legal process is obtained.
10. No Voluntary Disclosure Beyond Legal Requirement
Coded does not voluntarily provide user, merchant, or end-customer data to authorities. We disclose data only where we are legally compelled to do so by a valid request that satisfies these Guidelines and applicable law, or under the narrow emergency conditions in Section 9. We do not provide bulk access, direct or unfettered access to our systems, "back doors", or standing feeds of data, and we do not weaken security measures to facilitate access. We disclose the minimum data necessary and nothing further.
11. Cost Reimbursement and Format
Where the law allows, we may seek reasonable reimbursement of the costs of responding to a request. We respond in a reasonable format and within the time the law or the order requires; we do not commit to bespoke formats, real-time delivery, or expedited handling absent a legal obligation to do so.
12. How Authorities Submit a Request
Authorities should submit legal requests in writing to legal@coded.eu, on official letterhead or from an official government email domain. To help us review and respond efficiently and to allow us to narrow the request, please include:
- the issuing authority, the official's name and title, and verifiable contact details;
- the legal instrument relied on (subpoena, production order, court order, warrant, MLAT/e-evidence reference, or equivalent) and its legal basis;
- the specific account(s), Organization, project(s), or identifiers concerned;
- the precise data categories sought and the relevant time period;
- any deadline and the legal authority for it; and
- whether a non-disclosure obligation applies and its legal basis and duration.
We will acknowledge properly submitted requests and respond through the same channel. Requests sent to unrelated addresses or support channels may be delayed or redirected.
13. Transparency
We retain records of legal requests as reasonably necessary to operate this process, comply with our legal obligations, and defend our interests, consistent with our Privacy Policy. Where lawful, we may report, in aggregate and without identifying individuals, on the volume and nature of legal requests we receive.
14. Governing Law and Jurisdiction
These Guidelines and any dispute arising out of or relating to them are governed by the laws of the Netherlands, and the courts of Amsterdam, the Netherlands have jurisdiction, except that nothing in these Guidelines deprives a user of the protection of mandatory law of their own country of residence where that law applies and cannot be excluded by agreement, and these Guidelines do not limit the powers that any authority lawfully exercises under its own applicable law.
15. Changes to These Guidelines
We may update these Guidelines from time to time to reflect changes in law, our platform, or our procedures. When we make material changes, we will update the "last updated" date. The current version governs requests received while it is in effect.
Contact
For legal requests from authorities, contact legal@coded.eu.
For related matters:
- Data protection and privacy requests: privacy@coded.eu
- Security issues and vulnerability reports: security@coded.co
- Abuse, illegal content, and complaints intake: report@coded.co
- General support: support@coded.co
Coded B.V. — registered in the Netherlands; part of the Coded Holding B.V. group. KvK: 42027097 · VAT: NL869368795B01 · Registered office: De Taling 15, 2761 SL Zevenhuizen, The Netherlands · Managing director: Ibrahim Mohamed. Effective date: 11 June 2026.
<!-- OPEN ITEMS FOR COUNSEL: 1. Confirm the legal-instrument thresholds in Section 4 (subscriber info vs. non-content records vs. content/sensitive data) against current Netherlands criminal procedure (Wetboek van Strafvordering), GDPR, and the operational reality of what authorities can actually compel from a NL-established provider — and confirm the GDPR Art. 6(1)(c)/(e) framing for compelled disclosure and the Art. 23 expectation we place on authorities. 2. Validate the cross-border framing in Section 8: which mechanism actually applies to Coded as a NL-established provider — MLAT/letters rogatory, the EU e-evidence Regulation (EU) 2023/1543 / Directive 2023/1544 (and its application timeline), and the EU–US framework where relevant. Confirm we are not over- or under-stating what a direct foreign order can compel. 3. Confirm whether Coded has, or will have, any reporting/cooperation obligations as a provider under EU instruments (e-evidence designated establishment / legal representative requirement) and whether a legal representative must be appointed — this may require adding a representative contact. 4. Confirm the controller/processor split in Section 3 (merchant as controller of end-customer data, Coded as processor; Coded as controller of account/billing data) is consistent with the DPA, Privacy Policy, and Merchant Agreement, and that routing-to-merchant language is defensible. 5. Confirm the emergency-disclosure standard (Section 9) and the conditions under which we may disclose pre-process under NL/EU law without breaching GDPR; define an internal authentication/escalation runbook. 6. Confirm the user-notification default and the lawful grounds for delay/withholding (Section 7) against any NL gag-order regime and GDPR transparency duties. 7. Confirm cost-reimbursement entitlement (Section 11) under NL law. 8. Confirm scope/feasibility of any transparency reporting (Section 13) and whether any disclosure prohibition limits aggregate reporting. 9. Confirm the Stripe/Mollie redirect language for payment/cardholder data (Section 6) matches the processors' own law-enforcement procedures and our payment-data architecture; verify no PCI/processing claims overreach. 10. Confirm the Ibrahim Mohamed placeholder and entity details, and that legal@coded.eu is the canonical and monitored intake channel for authorities. 11. Confirm consistency of the Amsterdam-courts + mandatory-local-law carve-out with all other legal documents (ToS, Privacy, DPA, DMCA). -->