Privacy Policy

1. Controller

The controller responsible for the processing of personal data within the meaning of the General Data Protection Regulation is:

This Privacy Policy applies to the websites meykt.com, meykt.de, their subdomains and the use of the Meykt platform to the extent that Dumanu GmbH determines the purposes and means of processing.

Where customers use Meykt to process their own customer, employee, supplier, service provider, shop, order, file or production data, Dumanu GmbH usually acts as a processor within the meaning of Art. 28 GDPR. The respective customer remains responsible for such processing. Details are governed by the data processing agreement.

2. Privacy contact

For privacy questions, data subject requests or questions about the processing of personal data, Dumanu GmbH can be reached at info@meykt.com.

No data protection officer has been appointed.

3. General principles

We process personal data only where this is necessary to provide our websites, perform contracts, secure the platform, communicate with users, comply with legal obligations or where processing is based on consent.

Processing is limited to the data required for the respective purpose. Access within Meykt is role- and permission-based. Customer data is processed in tenant-separated environments.

4. Website visits and technical delivery

When our websites are accessed, technically necessary data is processed to deliver the website, operate it reliably and protect it. This includes in particular:

• IP address
• date and time of access
• requested URL
• referrer URL
• browser type and version
• operating system
• amount of data transferred
• technical error and security events

The processing takes place to provide the website, detect and prevent attacks, analyze errors and ensure operation. The legal basis is Art. 6(1)(f) GDPR. Our legitimate interest is the secure and reliable operation of our websites and services.

We use Vercel for hosting and delivery. Data may also be processed outside the European Union. For such transfers, we rely on suitable safeguards, in particular adequacy decisions, standard contractual clauses and supplementary protective measures.

5. Cookies, local storage and similar technologies

Meykt uses technically necessary cookies and comparable storage technologies to provide login sessions, language settings, security functions, routing and required platform features.

Technically necessary storage includes in particular:

• session and refresh cookies for login through Supabase Auth
• security cookies of two-factor sign-in: the confirmation of the current sign-in, when resetting or first setting the password a marker for the session from the link (no more than one hour) and — only if the person chooses it — a device remembered for 30 days (Section 8)
• locale or language cookies to store the preferred language
• cookies and local storage for selecting stations, machines or employees in production contexts
• local UI preferences such as navigation state, favorites or display options

The legal basis for technically necessary cookies and storage is Sec. 25(2) German TDDDG and Art. 6(1)(b) GDPR where they are required for contract performance, and Art. 6(1)(f) GDPR where they support secure and user-friendly operation.

We currently do not use any non-essential analytics, tracking or marketing technologies. The only exception is loading embedded YouTube videos, which happens only after you click (Section 6).

6. Analytics and embedded videos

We currently do not use any web analytics or tracking services that recognize visitors or track them across websites. Only the technical access data described in Section 4 is processed; we use cookies and similar storage only where they are technically necessary under Sec. 25(2) TDDDG (Section 5).

Should we use analytics or tracking services in the future, we will do so only with your prior consent under Sec. 25(1) TDDDG and Art. 6(1)(a) GDPR, which you can withdraw at any time with effect for the future. We will update this Privacy Policy accordingly beforehand.

Embedded YouTube videos

Briefings and request pages that customers design with Meykt may contain embedded YouTube videos; the respective business decides which video appears. When the page is opened, Meykt first shows only a neutral placeholder. No connection to YouTube or Google is established at that point, and no preview image is loaded. Only when you click “Load video” does your browser load the player via the youtube-nocookie.com address of YouTube, a service of Google Ireland Limited, Gordon House, Barrow Street, Dublin 4, Ireland.

Google then receives in particular your IP address, technical browser and device information, the origin of the calling page and the information which video is requested. While you watch the video, YouTube may use its own cookies or similar storage and may also transfer data to Google LLC in the United States; Google LLC is certified under the EU-U.S. Data Privacy Framework. Google is itself responsible for the processing by YouTube; details are set out in Google’s privacy policy (policies.google.com/privacy).

The legal basis for loading the video is your consent given by clicking (Sec. 25(1) TDDDG, Art. 6(1)(a) GDPR). If you additionally choose “Always load YouTube videos automatically”, your browser remembers this choice in its local storage; further videos are then loaded without another click but only play once you start them. You withdraw this choice by deleting Meykt’s stored site data in your browser; requests already made remain unaffected.

7. Contact and communication

If users contact us by email, form or support features, we process the information provided to handle the request. This may include name, email address, organization, role, message, technical information and previous communication.

The legal basis is Art. 6(1)(b) GDPR where communication is necessary for contract performance or pre-contractual steps, and Art. 6(1)(f) GDPR for general inquiries and support communication.

We use Resend to send transactional emails, invitations, system notifications, support emails and similar messages. Resend processes the necessary recipient, content, sending and delivery data. Where data is processed in the United States, we rely on suitable safeguards such as standard contractual clauses.

During registration, users may also optionally and separately from accepting the Terms of Service choose to receive news, practical tips, and information about new features and offers from Meykt by email. This choice is not required for registration, a trial, a contract, or use of the platform.

The choice initially triggers only a confirmation email using a double opt-in process. Its opaque link opens a confirmation page; consent is confirmed only after the user consciously presses the button on that page. Merely opening the email or the link is not sufficient. We do not send marketing emails without this confirmation. The confirmation link is valid for seven days, and only a cryptographic hash of the token is stored in our database. The confirmation email is sent as a plain-text message without an open-tracking pixel or rewritten tracking link.

To evidence and manage the choice, we process the user identifier, normalized email address, source and time of the choice, language, consent version and the wording shown at the time, the status and timestamps of the double opt-in process, and the IP address and user agent when confirmation is requested, completed or withdrawn. The legal basis for subsequently sending marketing emails is Art. 6(1)(a) GDPR. We retain evidence of consent to meet our accountability obligations under Art. 5(2) and Art. 7(1) GDPR; the legal basis is Art. 6(1)(c) GDPR. We process security and abuse-prevention data on the basis of Art. 6(1)(f) GDPR.

A pending choice or confirmed consent can be withdrawn at any time with effect for the future in the personal profile under “Email news” or by emailing info@meykt.com. Withdrawal does not affect the lawfulness of processing carried out before the withdrawal.

8. Registration, user account and organizations

When registering, logging in and using a Meykt account, we process in particular:

• name
• email address
• password or authentication data
• organization and organization role
• language, time zone and profile information
• login, security and session data
• invitation and permission data
• onboarding and usage settings

Processing takes place to create and manage the user account, authenticate users, separate tenants, assign permissions and provide the platform. The legal basis is Art. 6(1)(b) GDPR. Security and log data is also processed on the basis of Art. 6(1)(f) GDPR.

We use Supabase for authentication, database, storage and platform data. The Supabase project is currently operated in the Frankfurt am Main region. Supabase Auth may process session and authentication data. Google OAuth may optionally be used if users log in through Google.

So that nobody can try out passwords, Meykt records every failed password sign-in attempt (in the app and in the customer portal) in its own database: only a hash of the email address entered and a hash of the IP address, the area (app or portal) and the time — never the password, never the email or IP address in plain text. After eight failed attempts for the same email address or thirty from the same IP address within 15 minutes, Meykt accepts no further password sign-in for that period; “Forgot password?” remains available. We delete the entries after 24 hours. The legal basis is Art. 6(1)(f) GDPR (protecting accounts against unauthorized access).

Two-factor sign-in, remembered devices and security notices

Every person can set up two-factor sign-in for their Meykt account; the owner of an organization can require it for all members. Meykt then additionally asks for a code from an authenticator app at sign-in. For this, we process:

• an authenticator factor (TOTP) in Supabase Auth; to set it up or to remove a factor that was not set up through Meykt, Meykt sends a confirmation code via Resend to the confirmed sign-in address, and the code is stored only as a hash; Meykt also stores which factors were set up through Meykt and are therefore approved, when a factor was first confirmed and whether Meykt noticed that it was removed outside Meykt (two-factor sign-in then stays required until a new device is set up)
• recovery codes in case the authenticator app is lost: for each code only a slow cryptographic hash with its own random value (never the code itself), which codes have been redeemed, and a counter of the latest redemption attempts with any lock time that is stored permanently in the database so that codes cannot be guessed
• remembered devices if the person chooses “Trust this device for 30 days” at sign-in: on the device a random device identifier in a technically necessary cookie, on our side only its hash, a rough description derived from the browser identifier (such as “Chrome · Windows”) and the times of creation, last use and expiry — no IP address and no location
• the person's setting whether the code is requested at sign-in, and when Meykt turned it back on because of an organization with a requirement (for a one-time notice, deleted after the next sign-in with a code), as well as the organization's settings (requirement for all members, remembered devices allowed) with time and acting person; the owner sees in the member list whether a member has set up two-factor sign-in
• a technically necessary, signed cookie recording that the current sign-in meets the two-factor rule (valid for no more than one hour or 10 minutes respectively, bound to the sign-in), and, when resetting or first setting the password, a cookie of the same kind recording that the session has just come from the link in the email (no more than one hour, deleted after the new password is set)
• a session attestation for each sign-in that meets the two-factor rule: the account, the identifier of the sign-in session, how the rule was met (code from the authenticator app, remembered device — then its identifier — or code prompt turned off) and the times of creation and expiry. With it, the database itself checks on every access that the session has passed the two-factor check, and rejects access without it
• a record “code confirmed through Meykt” for each sign-in session: the account, the identifier of the session, the identifier of the authenticator device and the time of confirmation. Only with this record does Meykt treat a sign-in as confirmed with the code
• for each person a counter of code attempts: the times of the latest attempts with the code from the authenticator app, any lock (15 minutes after five wrong codes), the identifiers of the latest 20 code requests made by Meykt itself, and which of them Meykt rejected because the code had already been used, as well as the time of the latest warning email. With it we limit the guessing of codes and detect when a code was confirmed outside Meykt directly at the sign-in service or the same code was entered in a second sign-in shortly afterwards — such a code does not count in Meykt, and the person receives a warning email (for a second sign-in at most one per hour)
• security notices by email via Resend to the confirmed sign-in address when the password was changed, the code prompt was turned off, a device was remembered, an authenticator device was set up or removed or two-factor sign-in was removed, as well as when recovery codes were created or redeemed, too many wrong codes were entered, a code from the authenticator app was used outside Meykt or the same code was entered in two sign-ins shortly after each other or an authenticator device was removed outside Meykt, and the email with the link to reset the password; if the two-factor protection of an organization is relaxed (requirement turned off or remembered devices allowed again), all owners and admins of the organization receive a notice with the name of the organization and the change
• one-time “Wasn't you? Cancel” links in the notices about setting up and removing an authenticator device, about recovery codes and about support recovery: on our side only a hash of the link, the occasion, for support recovery the affected case, and the times of creation, expiry (7 days) and use. If a link is used, Meykt signs the person out on all devices, disconnects connected AI apps, forgets remembered devices or stops the support case, and sends a notice by email; authenticator devices and recovery codes stay unchanged — only Meykt support removes a device
• the times of attempts at “Change password”, to limit the number of attempts per person
• for a recovery by Meykt support (“authenticator app and recovery codes lost”): the case with the acting support staff and times, a verification code sent to the confirmed sign-in address (stored only as a hash), the proof from outside the mailbox — either the confirmation by another member with an admin role in one of the person's organizations (who, for which organization, when) or, only if there is no such member, which details only visible in Meykt the person named correctly (such as names of machines or workflows) —, any cancellation (who, via which channel) and the execution; if a case is stopped, the person receives an email. For the warning, the other owners and admins of the person's organizations — and, if it differs, the stored billing email address of every organization that the person leads as owner or admin — receive the person's name and sign-in address by email via Resend; the owners and admins additionally receive a notice in Meykt; the person receives an email and a notice in their open sessions. Every step is recorded in a log that cannot be changed afterwards

Recovery codes remain valid until they are redeemed, regenerated or removed together with two-factor sign-in; remembered devices for no more than 30 days and only until the person forgets them, changes their password, redeems a recovery code or removes two-factor sign-in; expired entries are deleted afterwards. Session attestations are valid for no more than 12 hours; we delete them on sign-out and as soon as their precondition no longer applies (for example device forgotten, factor removed, new password), and expired ones daily. We delete records “code confirmed through Meykt” on sign-out, as soon as the device used for the confirmation is removed or all sign-ins are ended, and otherwise after 30 days; the counter of code attempts one day after its last change, never during a running lock. The first confirmation and a noticed removal of a factor are stored with its approval and deleted with it. We delete “Wasn't you?” links 30 days after they expire, and the times of attempts at “Change password” after no more than one day. We store the state of a support case until the user account is deleted; by way of derogation from other security logs, we keep the support recovery log for three years, because it is meant to clarify and prove an account takeover (regular limitation period), also beyond the deletion of the account; it then only contains internal identifiers. We store settings until the user account or the organization is deleted. The legal basis is Art. 6(1)(b) GDPR for the secure provision of the user account and Art. 6(1)(f) GDPR for protecting accounts against unauthorized access and preventing abuse.

9. Use of the Meykt platform

When using Meykt Central, we process the data that customers and users create, import, upload or provide through integrations. Depending on usage, this may include:

• organization, location, station and machine data
• user, team, role and permission data
• employee data, workstations, production roles and availability
• customer and contact data
• delivery and billing data where stored in the system
• shop connections and shop metadata
• products, variants, article numbers, SKUs, prices and product descriptions
• orders, line items, shipping and customer data from shops
• production jobs, work steps, workflows, process states and logs
• approvals, briefings, quote data, service provider or customer portal data
• uploaded files, images, production files and technical attachments
• machine commands, machine status, telemetry, local action logs and Agent status
• support, error, audit and security logs

Where these data are processed to perform the contract with the customer, the legal basis is Art. 6(1)(b) GDPR. Where data is processed for security, error analysis or abuse prevention, the legal basis is Art. 6(1)(f) GDPR. Where statutory retention or evidence obligations apply, the legal basis is Art. 6(1)(c) GDPR.

For personal data that customers process in Meykt relating to their own end customers, employees, service providers, suppliers or shop customers, Dumanu GmbH usually acts as processor. The customer remains responsible for lawfulness, notices, legal bases, deletion periods and data subject rights.

10. Shop connections and external integrations

Meykt can be connected to external shop and platform services, for example WooCommerce, Etsy, Shopify, Amazon, eBay, the order management service Billbee or future providers. Such connections are actively configured by the customer.

Meykt connects to all shop platforms directly: the access tokens or API keys required for the connection are stored by Meykt in its own database and used exclusively for the connection set up by the customer. All traffic to and from the platforms runs exclusively over encrypted connections (TLS); access to the stored credentials is restricted to the respective customer organization, and other organizations cannot technically use them. Meykt does not store the password of your shop account. Where a platform provides a separate API password for access, that password is stored encrypted.

Depending on the connected platform, the following data in particular may be processed:

• shop name and shop URL
• connection status and technical configuration
• external product and order IDs
• product, variant and order data
• customer data from shop orders
• payment, shipping and fulfillment information where provided by the shop
• raw API response data for mapping, traceability and error analysis

ERP API and updates: On the customer’s instructions, Meykt processes articles and goods conditions, inventory, inbound deliveries, orders including addresses, personalization, notes and files, and shipping and return records through authorized interfaces. Authorized fulfillment partners receive the information released for their work. The customer chooses the connected systems and subscribed updates. Selected events and their data are sent to the receiver address configured by the customer; further information can be retrieved within the granted permissions. Technical delivery records support troubleshooting and prevent duplicate processing of repeated requests.

Optional Shopify publication: When the customer grants the required Shopify permissions and activates the function in Meykt, Meykt sends explicitly assigned available quantities to selected Shopify locations. When shipping publication is active, actual shipped quantities, their order and package references, carriers and tracking numbers are sent to Shopify. A notification to the shop customer is requested only according to the selected setting. Responsibility for publication is explicitly configured; connecting the shop alone does not activate it. Pausing prevents further scheduled publications but does not undo data already sent. A previously started operation may still complete.

Etsy in detail: For Etsy, every business connects only its own shop, by signing in to Etsy and granting Meykt the corresponding authorization. Access is read-only — Meykt writes nothing back to Etsy: no listings, no prices, no inventory, no order or shipping statuses. The only data read is:

• orders of the connected shop, including the details submitted by the buyer (for example name and delivery address) and personalization texts, such as a requested engraving text
• listings of the connected shop
• shop master data such as shop name and shop identifier
• the email address of the connected Etsy account, so that the connection can be assigned to the correct account

This corresponds to the four Etsy read permissions “transactions_r”, “listings_r”, “shops_r” and “email_r”. Meykt does not request any further or write permissions.

Billbee in detail: Billbee is an order management service that the business itself uses. The business connects it to Meykt by entering its Billbee user name and an API password intended specifically for this purpose; the API password is stored encrypted. With these, Meykt retrieves on a read-only basis the shop accounts of the Billbee account and the orders of the shop accounts selected by the business, including the buyers’ details (for example name, billing and delivery address, email address and telephone number, where available in Billbee) and personalization details. Meykt writes nothing back to Billbee. In doing so, Meykt transmits to Billbee only the credentials, Meykt’s technical API key and the retrieval parameters (for example time range and shop selection). Data is retrieved at the business’s initiative: when it sets up the connection, starts a synchronization or has switched on automatic synchronization. Billbee is not a service provider engaged by Meykt but a system of the business; processing at Billbee is governed by the business’s own contract with Billbee.

Purpose: The data read from a connected shop is used solely to fulfill the respective business's orders, including production, warehousing and shipping — for example to turn an order into a production job with the matching engraving text and to steer its processing. It is not used for Meykt's own purposes, for advertising or for market and competitive analysis. Data from different shops and from different customer organizations is never merged, never compared with one another and never analysed across organizations.

Meykt does not pass this data on to third parties on its own initiative. It is handed to another business only when the customer initiates it: if the customer engages a production partner through the fulfillment feature, the order items they release for that purpose are transferred, together with the associated details, to that partner's organization. The customer decides per order what is handed over; without such a release, each organization sees only its own data. Via AI access, the provider of an AI application receives this data only if a business to which the data is accessible in Meykt connects its own AI application to Meykt – that is, the customer or, for order items handed over to it, a production partner – and then only to the extent that business has released there. Independently of this, the AI service provider engaged by Meykt under Section 13 (Gemini API provided by Google) processes order data insofar as the customer uses the AI features described there.

Customer control: A business can disconnect a shop connection at any time in the Meykt dashboard. Access ends immediately and no further data is retrieved from the shop. For Etsy and WooCommerce the stored access tokens or credentials are deleted in the process. For Shopify the Meykt app stays installed in the shop until the business uninstalls it there; the authorization can be revoked at any time in the Shopify admin. In addition, the authorization can be revoked at any time directly at the platform itself. Order and listing data already imported remains in the business's account until the business deletes it or the periods set out in Section 17 apply.

Questions about a shop connection, about the data processed through it or about its deletion are answered at info@meykt.com. This address is monitored by us and is expressly open to sellers on the connected platforms as well.

Shipping settings: On the customer’s instructions, Meykt stores carrier accounts, contract identifiers, sender and return addresses, parcel shipping profiles, cartons and source mappings. Separately entered credentials are stored encrypted; the interface and connected AI applications receive only their setup status when reading, never their values. The customer can replace or remove the credentials. This setup alone does not submit shipments or recipient data to carriers or purchase labels. Change receipts containing the acting person and settings values allow repeated save requests to be identified; they contain no credentials.

Order package preparation: On the customer’s instructions, Meykt stores the intended shipping recipient address, selected shipping profile, and carton, outer dimensions and total weight for each package within the platform, including as an incomplete draft while packing. The preparation and its business change receipts contain the details saved at the time, the acting person, timestamp and any change reason; they may contain names, addresses and other contact details entered. Receipts make changes traceable and allow repeated or unanswered save requests to be resolved. An alternative recipient address applies only to the intended shipment; it changes neither the executing order’s address nor that of a fulfillment source order. Saving transmits no data to carriers, creates no shipping labels, records no stock movements and confirms neither packing nor dispatch.

DHL connection test: When the customer or an AI application enabled by the customer for this purpose starts a test of a saved DHL account, Meykt sends its DHL username and password together with Meykt’s central technical API credentials to DHL over an encrypted connection to check authentication in the selected sandbox or production environment. Any access token obtained is used only for the protected test request and is disclosed neither to the interface nor to an AI application. The public shipping endpoint is also checked for reachability; this does not prove permission to ship. The test sends no sender or recipient addresses, validates no billing numbers and creates no shipments or shipping labels. Its time-specific result is not a permanently stored connection status for the account.

DHL shipping profile validation: In this separately initiated test, Meykt submits a saved shipping profile with explicitly supplied recipient and parcel details to DHL. Authentication uses the saved DHL credentials and Meykt’s central technical API credentials. The validation request contains the selected shipping product, contract/billing number, saved sender details (name, company where applicable, address and email address), entered recipient (name, company where applicable, address and address addition), total weight, outer dimensions and shipment date, and any supported reference, cost centre or additional service, including the selected insurance amount or age threshold. A recipient email address is transmitted only if permitted by the profile; transmission of a recipient phone number is not supported by this validation flow. Transmission is encrypted and uses the displayed DHL sandbox or production environment. Validation covers ordinary street addresses within Germany with DHL Paket or DHL Kleinpaket; unsupported options, international destinations and special addresses are rejected.

Before starting, the Customer can review the exact details and confirms transmission in the interface; connected AI applications are subject to the separate permissions described under “AI access”. The test creates no shipping labels or shipments, changes no orders, records no stock movements and starts no workflow. The result applies only to the reviewed details at the time of validation and is not stored as a permanent validation status on the profile or an order. Changed settings or credentials prevent an outdated result from being presented as current success. Failed or unanswered requests are not automatically retried. Storage of AI requests and action records is described below and is distinct from this temporary validation result.

DHL shipping labels: When separately instructed to create a label for a fully packed package, Meykt sends the saved sender, recipient, contract and parcel details, selected shipping product, shipment date and supported additional services to DHL. The data fields and limits described above for shipping profile validation apply, including transmission of the recipient email address only when permitted by the profile. Authentication uses the saved DHL account and Meykt’s technical API credentials; transmission is encrypted and uses the displayed sandbox or production environment. DHL is used under the customer’s own business customer contract.

Meykt stores the specific label instruction with the transmitted details, order and package references, acting person, timestamps, processing status and any shipment number, together with the original PDF received. Records of cancellation attempts and retrieval of the original are also kept; these data may contain names, addresses and contact details. Authorized people and appropriately enabled AI applications can retrieve the original through a time-limited download. Uncertain outcomes remain identifiable as such; a creation request that may already have been sent is not automatically sent again. Label creation, cancellation and retrieval confirm neither printing nor the actual handover of goods and do not themselves debit stock.

Through the public customer API, customers can connect their own systems. They may register their own destination address to which Meykt sends status notifications about their orders. These notifications contain order and line item data and are sent to the server designated by the customer. The recipient and destination are determined solely by the customer; Meykt sends only on their instruction. Failed deliveries are logged for traceability.

The legal basis is Art. 6(1)(b) GDPR where the integration is used for contract performance. Where technical logs are processed for security and troubleshooting, the legal basis is Art. 6(1)(f) GDPR.

The customer is responsible for connecting only those shop and third-party accounts for which they are authorized and for informing their own customers about processing by connected systems.

AI access (MCP)

In the “AI access” area, the owner of a customer organization can connect an AI application of a third-party provider of their choice to Meykt via the Model Context Protocol (MCP) — currently Claude and Claude Code (Anthropic) as well as ChatGPT and Codex (OpenAI). The feature is switched off by default. Only the owner themselves can switch it on, neither an administrator nor a Meykt support access; beforehand, the owner confirms notices about the associated risks. The owner starts each connection in the AI application and then confirms it in Meykt with a second factor. Sign-in uses OAuth.

What data the AI application receives: The connected AI application retrieves data of the organization. It receives only data accessible to the organization in Meykt, and of that only the categories the owner has released:

• by default, operational data, for example orders, products, production, workflows, machines and stations as well as the organization’s settings and statistics, including the names, roles and skills of employees recorded in Meykt and their working and assignment times (for example who worked on which order, at which station or on which machine and when, with duration and completed quantity, also evaluated per employee as in the statistics) as well as the company names of business partners; this also includes general free-text fields and file names, for example production or order notes and internal help messages, whose content the AI application receives even without the switch for customer data
• personal data of end customers and contact persons, for example names, addresses, email addresses and telephone numbers, personalization details (such as engraving texts), customer notes and answers in process requests, email addresses and telephone numbers of employees, as well as the unmodified raw order data of connected shops and the run data of workflows, in each case including the prices and amounts contained therein, only if the owner expressly switches on the relevant switch and confirms the associated risk notice
• prices, amounts and payment details in the fields intended for them (for example totals, discounts, costs, hourly rates, credits and bank details) as well as the unmodified raw product data of connected shops only if the owner switches on the relevant switch; other billing and payment details such as plan, subscription status, billing periods and statement numbers, the payment status and payment time of orders, and the surcharges stored in kiosk options are part of the operational data
• the contents of files attached to orders, for example print files, customer images and previews, via a download link valid for a limited time, only if the owner, in addition to the switch for customer data, sets the switch “Manage files” to “Allowed”
• product designs, their images and GLB models, selected fonts, preview captures and generated manufacturing files when data and customer data are enabled and the connected person may view the design in Meykt. An interactive view loads the required media in the AI application's browser. Requested captures are returned to that application; if it supports its own file uploads, captures are first uploaded to its provider for that purpose. Meykt imports design files supplied by the customer in the AI application at their request. The provider receives this data under the terms of the connection chosen by the customer.

Meykt never transmits to the AI application credentials or other secrets – for example passwords, including that of a mail server, tokens, API keys, PINs and employees’ personal codes – and the AI application cannot enter them either; the owner does that themselves in Meykt. The AI application receives data of other organizations only insofar as that data is already accessible to the customer’s own organization in Meykt (for example shared fulfillment operations). When the AI application searches the Meykt help center, Meykt processes the search text via the AI service provider named in Section 13 (Gemini API provided by Google); Meykt removes email addresses and telephone numbers beforehand insofar as they are recognizable as such, and at most 300 characters are transmitted.

What the AI application can create, change and trigger: Nothing without a decision by the owner: all switches for this are initially set to “Off”. Only insofar as the owner sets one of them to “Ask” or “Allowed” does the AI application create and change data of the organization or trigger operations on behalf of the customer, in the following areas:

• Catalog (“Edit products, compiler and variables”): create, change, archive and restore products including price tiers and production setup; variables and variable groups, compiler mappings and compiler modules including their assignment; recompiling orders; custom fields and their values; set rules of shop connections – always as a complete list, so that rules missing from it are removed –; linking shop items with products and creating products from them; materials, suppliers, categories and properties, parameter recipes and adoptions from the Meykt library; releasing own products to a production partner
• Workflows (“Edit workflows”, “Publish workflows”): create, change and discard drafts – no workflow run uses a draft before it is published –, test automations with an order of the organization as a simulation without any commands being sent to machines or the Meykt Agent, create and change print templates, create card templates, create and change scan triggers, and publish workflows and switch them on and off
• Orders and production (“Edit orders”): edit orders as in the order editor (for example personalizations, items and quantities), set the status of production jobs, production orders and of orders created at a kiosk or manually – and also complete such orders –, mark orders as paid, decide on shop changes, fetch orders and failed files again, resolve items under “Needs attention”, create and change customers, create test orders with invented details that are never produced and notify nobody, start production, create, assign and complete production jobs, repeat and complete production runs, run automations live for orders, in fulfillment hand orders over to a production partner and request changes there and, as a production partner, set the status, answer requests and start production, answer internal help requests from employees and leave production runs out of the statistics
• Warehouse and material (“Edit warehouse”, “Edit capacity and experience”, “Edit box areas”, “Pack orders”, “Edit material stock”): set up storage locations and stock articles, set up box areas and their arrangement and create, assign and edit empty order boxes – only with the warehouse management permission and if the switch for customer data is also switched on –, book receipts, transfers, reservations and justified count corrections, maintain capacity and putaways, maintain shared storage forms and their article assignments, add package dimensions and record warehouse experiences and capacities for existing own or released customer products – only if the switch for customer data is also switched on –, reserve, pick, return and pack whole orders – when packing, Meykt books out no goods and ships nothing; only used shipping cartons for which the customer keeps a stock are deducted from that carton stock when packing is completed –, purchase material, book it in and out, transfer it and produce it from bills of materials, and book the used tool life of tools; in each case with the warehouse or material permissions of the person whose connection it uses
• Shipping (“Ship orders”, “Edit shipping settings”, “Test shipping connections”): record the actual handover of all packages of a completely packed order – Meykt then debits the held quantities, closes their reservations, marks the executing order as shipped and releases its order box; for this, the AI application must obtain an explicit human confirmation of the actual handover, which a scan or packing status does not replace –, create, change, activate and deactivate carrier accounts without credentials, contract assignments, parcel shipping profiles, cartons and shop shipping-method mappings, and check authentication and public reachability for a saved DHL account (see “DHL connection test”); in each case only if the switch for customer data is also switched on and with the warehouse and order permissions of the person whose connection it uses, for shipping settings and connection tests additionally with the warehouse management permission. The owner enters credentials themselves in Meykt; the AI application receives neither them nor an access token or unfiltered responses from DHL. This dispatch confirmation and this setup do not themselves create shipping labels; the separate label feature applies to that. They do not report a shipment to shops or fulfillment customers
• Package preparation (“Prepare shipping packages”): read and save recipient, shipping profile and package details as preparation for a claimed packing order. Writing requires a separate critical capability, initially off; permissions for packing, dispatch confirmation, shipping settings or profile validation do not replace it. Read data, full Read customer data access, and warehouse and order viewing rights are also required; saving additionally requires warehouse booking permission and the connected person’s editing rights for the packing order. Every save and every recovery of an earlier save receipt requires human approval of the exact request by the owner in Meykt, even with “Allowed”. Receipt recovery is bound to the original person and unchanged operation; it cannot make a first save or overwrite a later correction. A preview saves nothing. Before execution, Meyki requires explicit confirmation of the exact details. Recipient and package data included in AI requests, previews and action records are subject to the existing rules for requests and actions. Package preparation itself initiates no transmission to carriers.
• Shipping profile validation: technically validate a saved shipping profile with explicitly supplied recipient and parcel details at DHL. This has its own capability, initially off, with “Ask” and “Allowed” modes. With “Ask”, each specific test requires approval in Meykt; with “Allowed”, the AI application may directly initiate the test, including the data transmission described above. Data and customer data access and warehouse management permissions are also required. A preview alone sends no data to DHL. Approvals are bound to the exact details, selected profile, account, environment and reviewed settings and credential versions; changed details or settings require a new review and approval. Permission for connection tests or editing shipping settings does not replace this separate capability. Before execution, Meyki requires explicit confirmation of the exact preview.
• Shipping labels (“Manage shipping labels”): request DHL labels for already packed packages, inspect known shipments and cancel labels; only creation requests proven not to have been sent can be continued. This separate capability is initially “Off”. With “Ask”, the owner approves the exact preview in Meykt; with “Allowed”, the connected AI application may execute directly. Data and customer data access and the connected person’s warehouse booking and order permissions also apply. A preview alone sends nothing to DHL. Meyki requires explicit confirmation of the exact preview. The existing rules for AI requests and action records also apply to recipient and parcel details they contain. The AI application receives no credentials or access tokens; labels, printing and actual dispatch remain separate operations.
• Business setup (“Set up the business”): locations, machines and machine groups, stations and their assignments, employees and work teams, tools, service providers, names and workplaces of Meykt Agents and the assignment of machines to them, kiosks including categories, products, options, checkout fields and translations, the settings, fetch schedule and product selection of shop connections; pausing and resuming automatic import sources; also triggering order and product syncs and fetches from import sources, resending deliveries of the customer API, signing people out of stations and revoking paired terminals
• Processes (“Edit processes”): create and start process requests, complete internal steps, write notes, add customers or service providers as participants or revoke their access, send emails from steps, complete or cancel requests, and maintain process templates and their translations
• Files (“Manage files”): correct vector files with the steps of the vector check, vectorize, cut out or repair images and attach the result as a new file to an order item – the original is kept –, and upload and archive fonts
• Product design (“Edit product designs”): create own design libraries, import images, vectors and GLB models, generate simple 3D shapes from dimensions, save designs including customer rules and generate manufacturing files at real scale. This switch starts off. Data releases and the connected person's tool or product permissions also apply. Generating a file does not load or start a machine.
• Settings (“Change settings”): language, time zone, currency, VAT rate, measurement system and paper format, scanner defaults, staff notifications and email sending profiles including a connection test, as well as bug reports and feature requests to the Meykt team in the name of the connected person
• Service billing (“Edit service billing”): create services with unit and default price, own business customers and service rules, and assign kiosks to a business customer. The capability is initially off; customer data and price permissions and the connected person's permissions also apply. Every change requires owner approval of the specific preview, even with “Allowed”. This does not change the Meykt subscription, its plan or payment methods.
• Machines (“Check machines and Meykt Agent”, “Load files into LightBurn”, “Start laser”): ask LightBurn at a machine whether it is free – this changes nothing at the machine –, load a file into LightBurn and start the job loaded there
• final actions (“Delete permanently”, “Cancel orders”): permanently delete products, workflows and variables that are no longer in use, empty variable groups, switched-off compiler mappings and modules, unused custom fields as well as parameter recipes, and reset or delete production runs, in each case only if the switch of the area concerned is also switched on; cancel own orders – Meykt stops the production that has not started yet and keeps or credits the booked services as shown in the request –, cancel production runs, request the cancellation of whole orders or individual items from a production partner and, as a production partner, answer a client’s cancellation request; Meykt does not report cancellations to connected shops

In doing so, the AI application acts in the name of, and with no more than the permissions of, the person whose connection it uses. Many actions additionally require the switch for customer data or the one for prices, for example when they display or change such data; the AI application can create, change or assign variables, compiler mappings and compiler modules, recompile orders, save set rules (without exception, i.e. also when it merely removes rules) and test automations and publish or activate workflows only if both switches are switched on; merely switching off a compiler mapping or a compiler module and removing an assignment are exempt. The owner can turn on the critical switches “Publish workflows”, “Pack orders”, “Prepare shipping packages”, “Ship orders”, “Start laser”, “Edit service billing”, “Delete permanently” and “Cancel orders” only after confirming a separate risk notice; “Delete permanently” and “Cancel orders” only have “Off” and “Ask”. The AI application can never change members, roles and invitations, the Meykt subscription including its plan and payment-method management, security settings such as the requirement for two-factor sign-in, or the AI access switches themselves, create or delete shop connections or API keys, or delete the account or the organization. Meykt automatically deletes archived products – regardless of whether the AI application or a person archived them – 30 days after archiving, unless they appear in orders or are still in use (for example via a shop link, in a product structure or in a quote); until then, they can be restored.

With “Ask”, the AI application changes nothing itself but creates a request with a preview generated by Meykt that shows what would happen (for example previous and new values, for workflows a summary with the scope, the check result and the steps that require approval). Only the owner can approve or reject the request in the “AI access” area. Exactly the action shown is executed; Meykt does not execute entries whose target has changed since the request. A request can be approved only within 24 hours – an operation at a machine only within one hour – and only as long as the connection exists, AI access is switched on and the switch is not set to “Off”. With “Allowed”, Meykt executes the action directly. Even with “Allowed”, however, Meykt acts only after approval by the owner if an action can have particular consequences; these include in particular:

• effects outside Meykt or at another organization: sending emails from processes and any action in a process that opens a step for customers or service providers, makes something visible to them or gives them access; any fulfillment operation that reaches a production partner or client; tickets to the Meykt team; resending deliveries of the customer API; triggering order and product syncs with shops and fetches from automatic import sources, switching on an import source and switching a shop connection or its automatic fetching on or off; vectorizing an image; switching on a kiosk’s public catalog, which makes its products and prices publicly accessible
• effects at machines and PCs: every loading of a file into LightBurn and every start of a laser – Meykt passes the command to the Meykt Agent only upon approval and after checking again –, disconnecting a machine from its PC, and publishing, activating and running live workflows with steps that act beyond Meykt or control machines and PCs (for example sending emails, webhooks, handovers to production partners or commands to the Meykt Agent), and automations that start such workflows
• consequences in production: completing production jobs and runs; status changes that finish or fail a production order, complete an order or intervene in running production, or send an end customer an email; marking as paid if this starts production
• operations on goods: taking on, picking and returning orders, packing, package preparation including recovery of an earlier save receipt, confirming a shipment including clarifying an earlier shipping receipt, bookings for which the AI application states that a person has checked something on site, accepting an excess quantity that the delivery permits only after a query, closing a check although expected quantities are missing, saving capacity profiles and confirming counted occupied space, assigning articles to a shared storage form, and warehouse experiences and capacities recorded as confirmed on site
• interventions concerning people, devices and settings: signing people out of stations, revoking paired terminals, changing the organization’s currency or VAT rate, changing the server or sender details of an email sending profile with a stored password, every connection test of an email sending profile, and uploading a font
• data that flows into outputs, handovers or production: changes to variables that are used directly in one of the workflow steps mentioned or in a print template that such a step prints, or whose address Meykt downloads as a file, changes to the compiler mappings that fill such variables, and switching on, assigning, rebinding and renaming the compiler modules that fill such variables; values of custom fields that travel along on a handover to the production partner or are used in such a step or in a print or text template, and switching on this handover marking; set rules if such a workflow uses the details of the parts of an order (also via a print template it prints), if a workflow or an automation creates production jobs from the parts or takes them into account in doing so, or if the set rules stored so far cannot be read; recompiling orders in which such a file variable is filled or in which, for production jobs that are still open, the product structure (which parts the order comprises and which details are on them) would change or such a change cannot be ruled out
• assignments that cannot be taken back: linking shop items with products, in which case Meykt assigns older order items of that item to the product and recalculates their values, and creating products from shop items
• bulk: more than 20 status changes, payment or customer changes, test orders or production operations of the organization within one hour
• final actions: every permanent deletion, every reset of a production run and every cancellation – the switches for these have no “Allowed”. If such a request, together with the AI application’s final actions in the same area during the preceding 24 hours, concerns more than 20 entries, Meykt additionally requires, on approval, a code just entered from the approving owner’s authenticator app; from this number on, the AI application never deletes or cancels more than a quarter of all entries of an area – more is only possible in Meykt itself

If the AI application switches a compiler module off or removes an assignment, another active module of the customer may take its place; Meykt does not require a separate approval for this. The owner can undo many actions of the AI application in the “AI access” area as long as they are recorded in the change log: Meykt then restores the previous values, and for a publication the workflow’s previous live version; fields that someone else has changed in the meantime remain unchanged. Meykt takes back newly created entries insofar as this is possible without consequences for other data – depending on the type, by switching them off, archiving, cancelling or hiding them or, as long as they are unused, removing them –; otherwise, they remain in place. Meykt removes an attached result file of the image and vector tools from the order item again; credits used remain used. In particular, the following cannot be undone: final actions (deletion, reset, cancellation), warehouse, packing, shipping, material and tool-life bookings – the customer corrects a mistake in a warehouse or material booking with a justified counter-booking –, changes to shipping settings – the customer corrects them with a new edit –, connection tests, setting up box areas and order boxes, completing production jobs and runs, automations run live, signing people out and revoking terminals, fetching orders again and editing orders, decisions on shop changes, fetching files again, linking shop items and creating products from shop items, triggered syncs and fetches, handovers, requests and answers in fulfillment and starting production as a production partner, loading and starting at machines and disconnecting a machine from its PC, background removal and repair runs that have been started, completed process steps, completed or cancelled process requests and sent process emails, as well as answers to help requests and tickets to the Meykt team. Undoing does not reverse what an action has caused outside Meykt: sent emails, tickets to the Meykt team, resent deliveries as well as handovers, requests and messages to other organizations cannot be recalled.

Recipients and responsibility: The recipient of the retrieved data is the provider of the AI application chosen by the customer (currently Anthropic or OpenAI). Meykt does not engage this provider as its own service provider or sub-processor. The customer decides on the connection themselves; the transfer takes place at the customer’s initiative to the recipient they have chosen. The customer is responsible for the contractual relationship with the AI provider, including any data processing agreement that may be required, any transfer to third countries (the providers may also process data outside the European Union, in particular in the United States), the legal basis towards their end customers and employees, and informing them. What the provider does with the retrieved data is governed by its own terms; Meykt has no influence on data that has already been retrieved. Whatever the AI application creates, changes or triggers in Meykt is done on behalf of the customer and to the extent the customer determines through the switches and approvals in the “AI access” area.

Disclosures through actions of the AI application: If the AI application triggers an operation within the released scope, Meykt transmits data via the same channels and to the same recipients as for the same operation in the user interface; Meykt does not engage any additional service provider for this. This concerns in particular:

• emails to the customer’s customers, service providers or employees, for example from processes, about help requests or on status changes – depending on the operation via an email sending profile of the customer, i.e. via the customer’s own mail server, or via Meykt’s sending with Resend (Section 7)
• handovers, released product data, messages, change and cancellation requests, answers and statuses to the organization of the production partner or client involved in Meykt (fulfillment, Section 10)
• to participants of a process request – customers, service providers or a Meykt organization connected with them – the content that the process shows them
• bug reports and feature requests to the Meykt team, with the name and email address of the connected person (Section 7)
• resent status messages of the public customer API to the target address stored by the customer, as well as requests to the connected shops and to the customer’s automatic import sources when the AI application triggers a sync or fetch
• the username and password of a saved DHL account to DHL when the AI application triggers a connection test (see “DHL connection test”)
• for explicitly initiated DHL shipping profile validation, also the contract, sender, recipient and parcel details and supported options described under “DHL shipping profile validation” to DHL; this transmission cannot be undone and does not book a shipment
• for separately instructed DHL label creation, the shipping details described there to DHL; for inspection, retrieval of the original label from DHL or cancellation, also the already verified shipment number. Later cancellation of a label does not undo the data transmission
• commands to the Meykt Agent on the customer’s computers (Section 11)
• images that the AI application has vectorized, to the external service provider under Section 13a – only if the person whose connection the AI application uses has given their consent there themselves in Meykt and saved it for the current version of the notices, and only once the owner approves the run; the AI application cannot give this consent. Meykt processes background removal and image repair, as when used in the user interface, on its own hardware (Section 13b)

What Meykt itself processes for this purpose:

• the AI access settings: switched on or off, the time, person and version of the confirmed notices, and the position of the switches
• connection data: the connected app, an optional device name for local apps, the country code derived by the hosting provider from the network connection (for local apps, a change of country ends the connection), the times of connection and last use, the expiry, and the time and reason of any termination
• sign-in requests, authorization codes and tokens, with codes and tokens stored only as hashes, as well as a short-lived, technically necessary cookie that binds the sign-in to the browser in which it was started
• a fingerprint of the account’s security state (a hash of the email address, the stored password hash and the identifiers of the confirmed second factors), so that connections end as soon as the password, email address or second factors change
• for two-factor confirmation, an authenticator factor (TOTP) in Supabase Auth; to set it up or to remove a factor that has not been approved, Meykt sends a confirmation code via Resend to the confirmed sign-in address, and the code is stored only as a hash; Meykt also stores which factors are approved (details on two-factor sign-in and recovery codes in Section 8)
• a log entry for each call of the AI application and each change in the “AI access” area (including each approval, rejection and undo): time, app, tool or event, result, duration, the acting person (for calls, the person whose connection was used), and the names of the data types and fields queried, the number of results or of affected entries and, for changes, the level of the switch, where applicable the reason why approval is required, and the identifier of the request or action — no content of the queried or changed data. The log can be viewed by the organization’s owners and administrators.
• a change log for each action by which the AI application creates or changes data or triggers an operation: time, app, tool, the person whose connection was used, for an approved request the approving person, for an undo the person undoing it, status and counts, and for each affected entry the previous and new values of the changed fields (for a changed or discarded workflow draft, the complete previous draft) and, for operations that cannot be undone, the details that make them traceable – for example the booked details of a booking, the name and identifiers of a permanently deleted entry, or the way and billing decision of a cancellation. These values may contain personal data insofar as such data is contained in the affected fields (for example names and contact details in a changed customer record, personalizations in an edited order, the content of a workflow step or the values calculated from an order, including the raw values read for them); Meykt uses them so that the action can be undone or traced. The actions can be viewed by the organization’s owners and administrators in the “AI access” area; the AI application cannot retrieve the change log.
• for DHL connection tests initiated by the AI application, also the reviewed account and client references, environment and versions, approval and execution details and limited result information in the request and action logs; no credentials, access tokens or unfiltered DHL responses. The retention periods for requests and actions below apply. Such a record remains a historical test execution, not a current connection status.
• for shipping profile validation through AI access, also the specific request and preview including entered recipient and parcel details, profile, account and client assignments, environment and versions, and approval, execution and limited result information. These records may contain personal data. The retention periods for requests and actions below apply; credentials, access tokens and unfiltered DHL responses are not stored. Such a record is not a permanently valid validation result for the profile or an order.
• requests of the AI application (with “Ask” and for operations that require approval): tool, switch, connection, the checked details supplied by the AI application (for example product or customer data, the complete definition of a workflow, the message to a production partner or client, or the text of a ticket to the Meykt team), the preview generated by Meykt with previous and new values, the times of creation, expiry, decision and execution, the person who approved or rejected the request, and status and result. Open requests including their preview can be viewed by the organization’s owners and administrators in the “AI access” area; the AI application only learns the state of its own requests (status, times, counts and, where applicable, an error code), not their preview.
• workflow drafts of the AI application: name, description, complete definition, revision counter, times, and the person and connection with which the draft was created. Drafts are part of the organization’s data; the AI application can retrieve them.
• before each publication, activation and deactivation of a workflow by the AI application and before a publication is undone, the workflow’s previous live version (name, description, definition, active state, type of trigger, time, acting person) as a revision. Meykt uses revisions only to undo actions; neither the AI application nor the user interface displays them.
• for each simulation test run of the AI application – as for test runs in the Studio – a test session (workflow, selected order, the person whose connection was used, and the intermediate states created during the test run) and a run log of the test run with the data of the selected order. Both are part of the organization’s workflow data.
• tickets that the AI application sends to the Meykt team – like tickets from the user interface, with the name and email address of the connected person as the reporting person.
• the results of the image and vector tools as a new file on the order item. They are part of the organization’s data.

To limit the request rate, Meykt counts calls per connection and per organization and, during sign-in and when tokens are renewed or revoked, also per IP address. These counters are held exclusively in the memory of the respective server instance; they are not stored permanently and are not transmitted to any further service. This does not apply to the counter of recovery-code redemption attempts, which Meykt keeps permanently in the database (Section 8). Meykt determines the limits for actions of the AI application (for example open requests, directly executed actions and simulation test runs per hour, the bulk thresholds mentioned and status queries to machines) from the requests, the change log, the test runs and the machine commands in the database; no separate counters are created for this. Meykt counts allowances and credits, for example those of the image and vector tools, as for use in the user interface.

Retention: Log entries are retained for 180 days and then deleted by a daily clean-up run. The same applies to actions in the change log, including the previous and new values; after that, the action can no longer be undone. The same run deletes sign-in requests, authorization codes, email codes and tokens once they have been expired for more than one day. The same run deletes requests of the AI application, including their details and preview, 180 days after the decision on them or, if no decision was ever made, 180 days after they expired; it deletes revisions 180 days after they were created. If the associated action is still in the change log at that point, the request or revision is kept until that action is deleted; revisions are also deleted earlier together with the workflow or the organization. A workflow draft is deleted as soon as it is published or discarded; otherwise, Meykt stores it until the workflow or the organization is deleted. Meykt stores test sessions and run logs of simulation test runs, like test runs in the Studio, until the workflow or the organization is deleted; test sessions also end with the user account of the person whose connection was used. A connection ends after 30 days at the latest (cloud apps such as Claude and ChatGPT) or 14 days (local apps such as Claude Code and Codex); after that, a new sign-in with a second factor is required. Meykt stores settings and ended connections for traceability until the organization or the user account is deleted (Section 17). A connection no longer appears in the “AI access” area once it has been disconnected – by the owner or automatically; the log records that it was disconnected and why.

Disconnecting and switching off: The owner can disconnect individual connections and change the releases at any time in the “AI access” area. If the owner switches AI access off, all connections are disconnected immediately and authorization codes not yet redeemed are discarded. When connections are disconnected and when AI access is switched off, Meykt also discards the open requests of the connections concerned. Connections also end when the person is no longer the owner or when the password, email address or second factors change. Data the AI application has retrieved up to that point remains with the AI provider under its terms. The owner can still undo actions by which the AI application created or changed data, insofar as they can be undone and as long as they are recorded in the change log.

The legal basis is Art. 6(1)(b) GDPR for the feature set up by the customer. Where Meykt processes security data and the log to secure the connections, prevent abuse and ensure traceability, the legal basis is Art. 6(1)(f) GDPR. For personal data that the customer processes in Meykt about end customers, employees or business partners, Dumanu GmbH acts as a processor in accordance with Section 9: it makes such data available to the AI application only on the customer’s instructions, and likewise on the customer’s instructions it creates and changes data and triggers the operations described when the AI application initiates this within the released scope, and keeps the change log, requests, workflow drafts and revisions for this purpose.

11. Meykt Agent and local machine control

The Meykt Agent is a local desktop application installed in the customer's production environment. The Agent can communicate with Meykt Central and, depending on configuration, perform local actions such as:

• receiving or executing machine commands
• communicating with local software or machine interfaces
• opening, providing, printing or transferring files to machines
• reporting status and result data to Meykt Central
• confirming or logging production steps

Personal and technical data may be processed, for example user identifiers, station data, machine assignments, production job data, file paths, file names, status messages, error logs and execution results.

Processing takes place to provide the local production features configured by the customer. The legal basis is Art. 6(1)(b) GDPR. Security and error data is additionally processed on the basis of Art. 6(1)(f) GDPR.

The customer decides which local machines, programs, files and automations are connected. The customer remains responsible for ensuring that the use of the Meykt Agent in their production environment is lawful, safe and covered under labor law and data protection law.

12. Payment processing and billing

Once paid plans are activated, we process payments, subscriptions and invoices through Paddle. Paddle is not merely a payment service provider but the seller of record (Merchant of Record): the subscription contract is concluded with Paddle, Paddle issues the invoice and remits sales tax and VAT. Depending on the payment method, Paddle processes in particular the following payment and billing data:

• name, company and billing data
• email address
• payment method and payment status
• invoice and tax data
• technical payment and fraud prevention data

Processing takes place for contract performance and billing on the basis of Art. 6(1)(b) GDPR and to comply with legal obligations on the basis of Art. 6(1)(c) GDPR. Because of its role as seller, Paddle is an independent controller for payment, invoice and tax data and not our processor; this applies in particular to fraud prevention, compliance, payment network obligations and statutory retention obligations. On our side we only store a subscription's payment account identifier, the chosen plan, its status and the billing period — no card or bank account details.

13. AI features

Meykt provides AI features, currently in particular an AI assistant for workflow support and AI-assisted translation features. Further AI features, for example to support evaluations, texts, mappings, data preparation or error analysis, may be added. AI features are used only where they are activated for the respective function or contractually agreed.

Depending on the feature, prompts, files, order data, product data, process data, technical logs or other content selected by the user may be transmitted to an AI provider. As AI provider we currently use the Gemini API provided by Google; this also applies to the public Meykt Community parameter assistant. Data may also be processed outside the European Union, in particular in the United States; the information in Section 16 applies. If further providers are integrated in the future, they will be listed in this Privacy Policy or in a subprocessor list.

The legal basis is Art. 6(1)(b) GDPR where the AI feature is part of the booked service, or Art. 6(1)(a) GDPR where separate consent is required. Art. 6(1)(f) GDPR may apply to security, quality and abuse protection measures.

Meykt uses AI services only with suitable contractual privacy arrangements. Customer data is not used by Meykt for its own model training purposes. Where an AI provider offers options to use customer data for model training or product improvement, such options will be disabled for business customer data where contractually and technically possible.

Logging and analysis of conversations with the account-based AI assistants: For the signed-in AI assistants (the assistant Meyki and the workflow assistant), Meykt stores for each message the text entered, the visible response, where applicable references to screenshots uploaded at the assistant’s request, the time, user account, organization and conversation identifier, and technical details such as the model used, token consumption and the credits charged. If someone rates a response as helpful or not helpful, the rating and the rated response are stored. For Meyki, the AI provider additionally classifies automatically, within the same request, whether a message indicates an error in Meykt, a gap in understanding or a feature request; this classification is stored together with an estimate of its confidence. If Meyki retrieves operational or customer data, that data may be contained in the responses and therefore in the logs.

The logs serve quality assurance and error analysis, abuse prevention and usage limits, the billing of credits and the improvement of Meykt and the help content – in particular to identify recurring questions, errors, missing explanations and feature requests. Staff of Dumanu GmbH authorized for this purpose can view and analyse the conversations across organizations; other members of the customer organization have no access to a person’s logs. The logs are not used to train AI models. The legal basis is Art. 6(1)(f) GDPR; our legitimate interest lies in a secure, reliable and understandable service and its further development. For billing credits, the legal basis is Art. 6(1)(b) GDPR. You can object to processing based on legitimate interests under Art. 21 GDPR (Section 18). For the retention period see Section 17.

Public Community parameter assistant: This assistant can be used without an account. It processes the question entered, the language, the public parameter cards selected for the answer and a randomly generated pseudonymous visitor identifier used to limit abuse and cost. Meykt does not permanently store questions and answers from this public assistant in its own database; only aggregated technical usage values such as request count, token volume, runtime and error status are recorded. Inputs are transmitted to Google to generate the answer. The legal basis is Art. 6(1)(f) GDPR; our legitimate interest is providing anonymously accessible, source-grounded parameter help and protecting it against abuse. To protect against automated bulk requests, Vercel BotID evaluates technical browser and device signals when a question is submitted; the content of the question is not analysed for this purpose. Users should not enter personal or confidential content.

Proposals for the public parameter library: Customers can propose one of their own parameter sets for inclusion in the public library. What is transmitted and stored by the Meykt team is the parameter set itself (procedure, material, thickness, machine, tool, settings, notes) together with a display name chosen by the submitter. On acceptance the display name is shown publicly and permanently next to the entry; anyone who does not want a personal reference should choose a company or made-up name. Organisation details, stock levels, prices, customer or order data are not transmitted. The legal basis is Art. 6(1)(a) GDPR (consent, given by deliberately submitting the proposal). Consent can be withdrawn at any time; a proposal that has not yet been decided can be withdrawn in the application, and an entry that has already been published will be anonymised or removed on request. To be able to report back on the decision we also store which account submitted the proposal; that link is never published.

Business profile of the AI assistant (memory): Upon request, the AI assistant can remember individual entries about the customer organization's business that have been confirmed by the customer (for example manufacturing processes used, sales channels or software in use) in order to tailor answers to the organization. This feature is only activated after an authorized representative of the customer organization has given prior express consent; the legal basis is Art. 6(1)(a) GDPR. Only entries that a user has expressly confirmed in the conversation or created in the settings are stored. All stored entries can be viewed, edited and deleted individually or in full by the organization in the settings at any time. The consent can be revoked at any time with effect for the future; from the moment of revocation the entries are no longer used. When the feature is active, the stored entries are transmitted to the AI service provider named in this section together with the chat input. Users should not store personal data of third parties (such as names or order data of end customers) in the business profile.

Meyki access to operational and customer data: Meyki uses the shared tools and field checks of AI access. Within the permissions of the person using it, Meyki can retrieve operational data of the customer organisation and personal customer data, including names, email addresses, telephone numbers, billing and delivery addresses, orders, personalization details and released shop and workflow run data. The retrieved details are transmitted together with the chat input to the AI service provider named in this section to process the request. Meyki can also prepare operations with the same tools; changes are performed only after an authorised person expressly confirms the specific preview. The logging and retention rules described in Section 10 apply to previews, approvals and action records; those records may contain the affected operational and customer data. Credentials and other secrets, and data inaccessible to the customer organisation, remain unavailable. Expanded access is activated only after an authorised representative of the customer organisation expressly accepts the current version. Earlier approvals for access excluding customer data are not carried forward. Each person using Meyki then personally acknowledges the current data access notice. The organisation's approval does not replace any required legal basis for processing customer data; the customer organisation remains responsible for it. The processor processes this data on instructions under the Data Processing Agreement. Approval may be withdrawn at any time with effect for the future; Meyki can no longer be used after withdrawal.

Meyki and connected AI applications: Meyki is provided by Meykt and transmits the data retrieved for the request to the AI service provider named in this section. If the customer connects a third-party AI application via AI access (Section 10), the owner controls its data scope and permitted actions through the switches there; the provider of that application is not an AI service provider engaged by Meykt. Both access routes use the same tools and field checks. Effective user permissions, organisation boundaries, required separate approvals and protection of credentials remain in place on both routes.

The customer is responsible for not entering particularly sensitive or legally protected content into AI features unless this has been expressly agreed and secured.

13a. Image vectorization

Via the “Vectorization” tool, users can convert raster images (for example logos) into vector graphics. For this purpose, the image file selected by the user is transmitted to and processed by an external service provider that specializes in image vectorization and is established in the United States.

The data processed includes in particular the uploaded image file, the resulting vector output and technical processing data (for example format, size and time of processing).

The transfer takes place only if the user actively triggers the feature and expressly consents to the transfer beforehand. The legal basis is consent under Art. 6(1)(a) GDPR. The associated transfer to the United States is based on Art. 49(1)(a) GDPR (explicit consent to the data transfer). Consent can be withdrawn at any time with effect for the future by no longer using the feature.

Note on third-country transfer: For the service provider used, there is no adequacy decision, no data processing agreement and no standard contractual clauses. There is therefore a risk that U.S. authorities may access transmitted data and that the user may not have the same level of legal remedies as provided within the EU.

Storage at the service provider: The service provider stores the uploaded file and the result temporarily under its own terms, currently for up to approximately two weeks; for account-linked records, storage may last longer. We cannot guarantee earlier deletion.

Use for training purposes: The service provider reserves the right to use transmitted images to develop, train and improve its own techniques and models. No objection to this is provided for at the service provider. Users should therefore not vectorize images containing personal data of third parties or confidential content, and should only upload images for which they hold the necessary rights.

The service provider acquires no rights in the resulting vector graphic; the results belong to the user within the scope of their rights in the source image. The feature is optional; users may instead use already vectorized files without using the external service.

13b. Image background removal

Via the “Background removal” tool, users can automatically remove the background of images (for example product photos). The background removal itself takes place on our own hardware within our infrastructure in the European Union; the image file is transferred there over an encrypted connection. For processing, the image is stored temporarily in our file storage at Supabase (Section 15). It is not transmitted to specialized image service providers and is not used for training purposes of third parties.

The data processed includes the uploaded image file, the resulting cut-out image and technical processing data (for example the method used, size and time of processing).

Processing takes place only if the user actively triggers the feature. The legal basis is Art. 6(1)(b) GDPR (provision of the feature requested by the user) and Art. 6(1)(f) GDPR (legitimate interest in operating the feature). Separate consent as for image vectorization is not required, because the image is not transmitted to an external image service provider.

Retention: The uploaded image file and the generated result are stored temporarily in our infrastructure to provide the feature (including automatic retries after technical errors) and are automatically deleted after no more than 14 days. Where the feature is embedded in other areas of the platform (for example to edit product images), the retention and deletion rules stated there additionally apply.

14. Security, abuse prevention and audit logs

To secure the platform, we process technical logs, authentication events, role changes, system events, API access, error data, security-relevant configurations and audit logs.

Processing serves to detect abuse, investigate security incidents, trace administrative changes and maintain service stability. The legal basis is Art. 6(1)(f) GDPR. Where legal obligations apply, the legal basis is Art. 6(1)(c) GDPR.

Error monitoring (Sentry)

So that we can notice and fix software errors on the website, in the help center, in the community and in the Meykt platform quickly, we use the Sentry service of Functional Software, Inc. (USA). The data is stored in the EU data region (Frankfurt am Main). When an error occurs, an error report is transmitted. It contains:

• technical error data: error message, error type and code location (stack trace), time, affected software version (release) and environment,
• the affected page as an address without access tokens from invitation, request, kiosk and connection links and without appended parameters (everything after “?” and “#”),
• browser, operating system and device type (from the browser identifier) as well as previously visited pages and network requests as addresses in the same shortened form.

Before sending, we replace email addresses, access keys, login tokens, IP addresses and database detail values in error texts with placeholders. Not transmitted are: your IP address as part of the error report (we do not send it and do not let it be inferred; it is technically visible for establishing the connection), cookies, authentication headers, entries in form fields, clicks, console output and form contents. There is no session recording and no performance or usage analysis; Sentry is not used for advertising or analytics purposes.

The legal basis is Art. 6(1)(f) GDPR; our legitimate interest lies in stable, secure and error-free operation. Sentry processes the data as our processor. For the transfer to the United States, see Section 16. Error reports are deleted automatically by the provider once the retention period applicable to our account has expired; we can delete individual reports earlier at any time.

15. Recipients and processors

We disclose personal data only where this is required for the purposes described above, where a legal obligation exists, where the user has consented or where another legal basis applies.

Service providers used by us include in particular:

The provider of an AI application connected by the customer via AI access (for example Anthropic or OpenAI) is not a service provider engaged by Meykt and is therefore not listed in this table; it receives data only at the customer’s initiative (Section 10). The same applies to shop platforms and services such as Billbee that the customer connects to Meykt itself (Section 10). YouTube (Google) receives data only if you load an embedded video and processes it as an independent controller (Section 6).

The specific list of subprocessors may change when services are replaced, added or extended. Material changes will be communicated in an appropriate manner where contractually or legally required.

16. International transfers

Some service providers we use are established or have processing capacities outside the European Union or the European Economic Area, in particular in the United States. Personal data may therefore be transferred to third countries.

Where data is transferred to third countries, we rely on suitable safeguards, in particular:

• adequacy decisions by the European Commission, such as the EU-U.S. Data Privacy Framework where the respective provider is certified
• standard contractual clauses of the European Commission
• supplementary technical and organizational measures
• contractual data processing agreements

In individual cases we use services for which none of the above safeguards (adequacy decision, standard contractual clauses or data processing agreement) is in place. This concerns in particular the image vectorization feature. The transfer to the United States is then based exclusively on the user’s explicit consent under Art. 49(1)(a) GDPR, after the user has been informed of the associated risks.

The Sentry error monitoring (Section 14) stores error reports in the EU (Frankfurt am Main). Because the provider, Functional Software, Inc., is established in the United States, access from the United States cannot be ruled out. We base it on the EU-U.S. Data Privacy Framework where the provider is certified and, in addition, on the European Commission’s standard contractual clauses in the data processing agreement with the provider.

Transfers to the provider of an AI application connected by the customer via AI access are initiated by the customer; the customer ensures that the requirements of Chapter V GDPR are met (Section 10).

17. Retention and deletion

We store personal data only for as long as necessary for the respective purposes or as long as statutory retention obligations apply.

In general, the following retention periods apply:

• User account and contract data is stored for the duration of the contract.
• During the running contract, the platform clears up certain content automatically. This concerns in particular photos and files from finished production orders and station runs; they are permanently deleted after a period that depends on the booked plan of 180, 365 or 730 days (retained indefinitely on the highest plan). Running or paused orders are not affected. Further automatic deletions concern cancelled and never-submitted requests (90 days), images in the image tools (14 days), automatically fetched import source files (30 days) and notifications (90 days). The periods applicable to each customer can be viewed in the application under "Settings → Usage & credits".
• After contract termination, platform and customer data is generally retained for 30 days to allow restoration, migration or mitigation of accidental termination effects. Afterwards, it is deleted or anonymized unless statutory retention obligations prevent this.
• Invoices, payment and tax-relevant documents are stored according to statutory retention obligations, generally for six to ten years.
• Double opt-in tokens are stored only as hashes and become invalid after seven days. Unconfirmed requests are retained only for as long as necessary for processing, troubleshooting and preventing abuse, and are then deleted or anonymized. Evidence of confirmed or withdrawn consent is retained for as long as necessary to meet our accountability obligations and defend against potential legal claims; it is then deleted or anonymized.
• Security, system and audit logs are stored only for as long as required for security, traceability and error analysis. Unless longer storage is necessary, they are generally deleted or anonymized after no more than 90 days. By way of derogation, entries in the AI access log and change log are retained for 180 days and then deleted automatically (Section 10).
• Logs of conversations with the account-based AI assistants, including ratings and screenshots (Section 13): there is currently no fixed deletion period; they remain stored for as long as the organization exists. The rule above applies at the end of the contract. If a user account is deleted, the link between the logs and that account is removed.
• Requests of the AI application connected via AI access, including their preview, for 180 days after the decision or after their expiry, and previous live versions of workflows (revisions) for 180 days after they were created, in each case not while the associated action is still in the change log, and revisions earlier together with the workflow or the organization; workflow drafts until they are published or discarded, at the latest until the workflow or the organization is deleted; test sessions and run logs of simulation test runs until the workflow or the organization is deleted (Section 10).
• Shipping settings and their business change receipts until deletion of the organization; individual settings that are no longer used may be removed earlier. Shipping credentials until replacement, explicit removal or deletion of the organization. After removal, only setup status, version counter, modification time and the acting person remain for as long as the account exists.
• Failed sign-in attempts (only hashes of email and IP address): 24 hours.
• Files of a data export of the organization: 48 hours, then deleted automatically; the owner can delete them earlier.
• Error reports in the Sentry error monitoring (Section 14): deleted automatically by the provider once the retention period applicable to our account has expired; we delete individual reports earlier where necessary.
• Two-factor sign-in data: recovery codes (only as hashes) until redemption, regeneration or removal of two-factor sign-in; remembered devices for no more than 30 days; session attestations for no more than 12 hours; records “code confirmed through Meykt” for no more than 30 days; counter of code attempts until one day after its last change; the time when the code prompt was turned back on because of an organization with a requirement, until the next sign-in with a code; “Wasn't you?” links until 30 days after expiry; support recovery log for three years; settings until the user account or the organization is deleted (Section 8).
• Backups are overwritten or deleted according to the applicable backup cycle. Targeted individual deletion from existing backups may be technically limited; in that case deletion takes place no later than at the end of the backup cycle.

18. Data subject rights

Data subjects have the following rights subject to the statutory requirements:

• access to personal data processed, Art. 15 GDPR
• rectification of inaccurate data, Art. 16 GDPR
• erasure, Art. 17 GDPR
• restriction of processing, Art. 18 GDPR
• data portability, Art. 20 GDPR — customers can export the data of their organization themselves as JSON at any time (Settings → Billing → Export data).
• objection to processing based on legitimate interests, Art. 21 GDPR
• withdrawal of consent with effect for the future, Art. 7(3) GDPR
• complaint with a data protection supervisory authority, Art. 77 GDPR

The supervisory authority responsible for Dumanu GmbH is:

19. Requirement to provide data

Providing certain data is necessary to access the website, create a user account, perform contracts, process payments or use Meykt features. Without these data, we cannot provide the respective services or can provide them only with restrictions.

20. Automated decisions

No automated decision-making within the meaning of Art. 22 GDPR currently takes place. The AI features in use also do not make decisions that produce legal effects or similarly significantly affect users. If features are used in the future that could have such effects, we will identify this separately and comply with legal requirements.

21. Changes to this Privacy Policy

We may amend this Privacy Policy if our services, providers used, legal requirements or technical processes change. The version published at the time applies.

For privacy questions, contact us at info@meykt.com.