Data Processing Agreement (DPA)

This English translation is provided for convenience only. The German version of this agreement is the legally binding version and prevails in case of discrepancies.

§ 1 Parties and incorporation

(1) This data processing agreement pursuant to Art. 28 GDPR (“DPA”) is concluded between the customer using the Meykt platform for its organization, processes, customer, employee, shop and production data (hereinafter the “Customer”, acting as controller), and

(hereinafter the “Processor”).

(2) This DPA becomes part of the main agreement governing the use of the Meykt platform upon acceptance of the Terms of Service. In matters of data protection law, this DPA prevails over the Terms of Service.

(3) The Customer is the controller within the meaning of Art. 4 No. 7 GDPR for the personal data it processes, or has processed, via the Meykt platform. The Processor processes such data as a processor within the meaning of Art. 4 No. 8 GDPR.

§ 2 Subject matter and duration

(1) The Processor processes personal data on behalf of the Customer for the provision, maintenance, security and further development of Meykt Central, Meykt Agent and the associated SaaS, integration, support and automation features. Processing takes place exclusively within the scope of this agreement and the Customer’s instructions.

(2) The Processor does not process the Customer’s personal data for its own purposes. The Processor may only evaluate aggregated, non-personal usage statistics for its own purposes; no link to individual persons is established in doing so.

(3) The duration of the processing corresponds to the term of the main agreement. After the end of the agreement, the handling of the data is governed by § 14.

§ 3 Nature and purpose of processing

Processing includes in particular:

• hosting and operation of the platform
• storage and processing of account, organization, shop, customer, product, order, file, production and workflow data
• authentication and permission checks
• shop and third-party integrations
• making data available to AI applications connected by the Customer and the creation and change of data and triggering of operations by these applications within the scope released by the Customer (“AI access”, § 6b)
• file uploads and file retrieval
• workflow and automation execution
• machine commands, agent communication and status reporting
• email dispatch on behalf of the Customer (e.g. invitations, notifications)
• payment and billing processes, to the extent processed on behalf of the Customer
• support, error analysis, security and audit logging
• AI-supported features, to the extent activated by the Customer and contractually provided for

§ 4 Categories of personal data

Depending on usage, the Processor processes the following categories of data:

• Master data: name, company, role, organization, contact details
• Account data: email, profile, language, time zone, roles, permissions
• Employee data: name, role, station, machine, work context, attendance or session data, where used
• The Customer’s customer data: name, email, phone, address, contact persons, order and communication data
• Shop data: orders, product data, shipping data, payment status, external IDs, raw API data
• Production data: jobs, work steps, files, process status, logs, machine assignments
• File data: uploaded images, production files, attachments, file names, metadata
• Integration data: connection configurations, tokens or OAuth data via sub-processors, technical status data
• Communication data: email contents, invitations, support messages, notifications
• Security and log data: IP addresses, login events, system events, error data, audit logs
• AI feature data: inputs, outputs, context data and files, where the Customer uses AI features

§ 5 Categories of data subjects

Depending on usage, the following persons may be affected:

• users and administrators of the Customer
• employees of the Customer
• customers and end customers of the Customer
• contact persons at customers, suppliers, service providers and production partners
• service providers, external release recipients or portal users
• shop customers whose data is imported from connected shops

§ 6 Processing on instructions

(1) The Processor processes personal data only on documented instructions from the Customer — including with regard to transfers of personal data to a third country or an international organization — unless required to do so by Union or Member State law to which the Processor is subject. In such a case, the Processor informs the Customer of that legal requirement before processing, unless that law prohibits such information on important grounds of public interest.

(2) Instructions result in particular from the main agreement, the product configuration and the workflows, integrations, user permissions, agent approvals and support requests set up by the Customer.

(3) If the Processor is of the opinion that an instruction of the Customer infringes the GDPR or other Union or Member State data protection provisions, it informs the Customer without undue delay. The Processor is entitled to suspend the execution of the instruction concerned until the Customer confirms or amends it.

(4) Approval of Meyki's current data access by an authorised representative of the Customer constitutes a documented instruction to transmit operational and personal customer data, within effective user permissions, to Google, the subprocessor named in Annex 2, through the Gemini interface to process the respective request. This may include names, contact details, billing and delivery addresses, orders, personalization details and released shop and workflow run data. Earlier approvals of the scope excluding customer data do not apply; after the current organisation approval, each person using Meyki personally acknowledges the expanded notice. Meyki uses the same shared tools and field checks as the connected AI applications under Section 6b; changes require express confirmation of the specific preview by an authorised person. User permissions, organisation boundaries, separate approvals for certain operations and exclusion of credentials remain effective. The Customer remains responsible for the legal basis for processing customer data. The Customer can withdraw approval at any time with effect for the future; Meyki is then no longer available.

§ 6a Data transfers within the fulfillment network

(1) Releasing order items to another Meykt customer for execution (a “fulfiller”) constitutes an instruction of the Customer. The Customer remains solely responsible for the legal basis of the transfer of personal data (in particular end-customer and shipping data) to the fulfiller. This also applies to multi-level onward transfers within the network.

(2) The Processor also acts as a processor vis-à-vis the fulfiller. No joint controllership within the meaning of Art. 26 GDPR is established.

(3) The Customer informs the data subjects pursuant to Art. 13(1)(e) GDPR about the recipient category “fulfillment service providers”.

(4) If the fulfiller has itself connected an AI application via AI access (§ 6b), that application can retrieve the data handed over to the fulfiller within the scope of the fulfiller’s releases; the fulfiller alone decides on this.

§ 6b Transfers to and changes by AI applications connected by the Customer

(1) If the Customer connects an AI application of a third-party provider of its choice to the platform via the “AI access” area (currently Claude, Claude Code, ChatGPT or Codex), making the data retrieved by that application available to it constitutes an instruction of the Customer. The Processor makes available only the data categories the Customer has released there; it does not make available fields in which the platform stores credentials or other secrets. It makes available the fields in which the platform holds names and contact data of end customers and contact persons, personalization details, raw shop data, workflow run data, customer notes, email addresses and telephone numbers of employees, and prices and amounts only if the Customer has separately enabled this; prices and amounts contained in raw shop order data or in workflow run data are made available already upon enabling of customer data. Surcharges stored in the kiosk option definitions form part of the operational data made available by default. The operational data made available by default also include names, roles, skills and working and assignment times of employees (for example who worked on which order, at which station or on which machine and when) as well as general free-text fields and file names, for example production or order notes; the AI application receives the content of these free texts even without separate enabling. It makes the contents of files attached to orders available only if the Customer, in addition to customer data, has enabled the downloading of files. It also does not accept credentials or other secrets from the AI application.

(2) If the Customer sets a switch for creating and changing data in the “AI access” area to “Ask” or “Allowed”, the creation and change of data and the triggering of operations by the AI application within the scope thus released also constitute an instruction of the Customer. This currently covers the catalog (products including prices and production setup, including archiving and restoring from the archive, variables, compiler mappings and compiler modules including their assignment, recalculating the values calculated from orders, custom fields and their values, set rules of shop connections including removing individual or all rules, links between shop items and products, materials, suppliers, recipes and releasing products to production partners), workflows and their templates, orders, customers and production including operations in the fulfillment network (§ 6a), warehouse, packing, shipping (confirming the actual handover of all packages of a completely packed order including debiting the held quantities, without buying shipping labels or notifying external services) and material, shipping settings (carrier accounts without credentials, contract assignments, parcel shipping profiles, cartons and shop shipping-method mappings), the setup of the business (locations, machines, stations, employees, teams, tools, service providers, Meykt Agents, kiosks, settings of shop connections and import sources, and triggering syncs and fetches), processes including emails to their participants, files of the image and vector tools and fonts, the organization’s settings and email sending profiles, the Customer’s service billing to its business customers (services, service rules and kiosk assignments), operations at machines via the Meykt Agent, and the permanent deletion of entries that are no longer in use and of parameter recipes, the reset and deletion of production runs and cancellation. The Processor does not enable the AI application to change members and roles, the Meykt subscription including its plan and payment-method management, security settings or credentials, or to delete the account or the organization. The AI application acts in the name of, and with no more than the permissions of, the user whose connection it uses. It always saves set rules as a complete list, so that rules missing from it cease to apply; the Processor enables it to save set rules only if the Customer has also enabled customer data and prices, without exception, i.e. also for merely removing rules. With “Ask”, the Processor executes an action only after the Customer has approved it in the platform. Even with “Allowed”, it requires such approval in the cases described in the privacy policy (Section 10, “AI access”), in particular for emails from processes and process steps that open or show something to customers or service providers, for operations that reach a production partner or client, for tickets to the Processor, for resent status messages and triggered syncs and fetches, for every loading of a file and every start at a machine, for publishing, activating and running live workflows and automations that act beyond the platform or control machines and PCs, for completing production jobs and runs, for picking, returning and packing orders and for confirming a shipment including clarifying an earlier shipping receipt, for certain changes to variables, compiler mappings and compiler modules, custom fields and set rules and for recalculating orders if their values flow into such steps, into file downloads, into handovers to production partners or into the product structure of running production, for linking shop items with products, for more than 20 status, payment or customer changes, test orders or production operations per hour, and always for permanent deletion, the reset of production runs and cancellation. If a request for permanent deletion or cancellation, together with such actions of the AI application in the same area during the preceding 24 hours, concerns more than 20 entries, the Processor executes it only if the approving user additionally confirms a code just entered from their authenticator app; from this number on, the Processor never deletes or cancels more than a quarter of the entries of an area at the instigation of the AI application. It deletes archived products – even if the AI application archived them – 30 days after archiving, unless they appear in orders or are still in use.

(2a) Separately enabled shipping connection tests also constitute an instruction of the Customer. This capability is initially switched off. With “Ask”, each test requires approval in the platform; with “Allowed”, the AI application may initiate it without approval per request, provided the required data access and user permissions are in place. When testing a saved DHL account, the Processor sends its username and password together with the Processor’s central technical API credentials to DHL over an encrypted connection to check authentication in the selected sandbox or production environment. It also checks public reachability of the shipping API; this does not prove permission to ship. The AI application receives only the limited, time-specific result, never credentials, access tokens or unfiltered provider responses. The test sends no sender or recipient addresses, does not validate billing numbers and creates no shipments or shipping labels. The mandatory approvals for other actions listed in paragraph 2 remain unchanged.

(2b) Separately approved shipping profile validation also constitutes an instruction of the Customer. The Processor validates a saved shipping profile with explicitly supplied recipient and parcel details at DHL. In addition to credentials required for authentication, it sends the saved shipping product, contract/billing number and sender details, entered recipient, total weight, outer dimensions and shipment date, and any supported references, cost centres and additional services to DHL; recipient email addresses 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 selected sandbox or production environment. Validation is limited to ordinary street addresses within Germany with DHL Paket or DHL Kleinpaket; unsupported options are rejected. It creates no shipments or labels, changes no orders and starts no workflow.

In the interface, the Customer confirms transmission of the exact details. Connected AI applications require a separate capability, initially off; permission to edit shipping settings or test connections is insufficient. Data and customer data access and warehouse management permissions are also required. With “Ask”, the specific request is approved in the platform; with “Allowed”, the AI application may directly initiate the specific test, including the data transmission described above. Approval is bound to the reviewed details and settings and credential versions. Meyki requires explicit confirmation of the complete preview. A preview alone does not contact DHL. Changed details require a new review and approval. Errors or missing responses do not trigger an automatic retry.

(2c) Order package preparation is processing on the Customer’s instructions within the platform. The intended recipient address, shipping profile, carton, outer dimensions and total weight for each package are stored, including as an incomplete draft while packing. An alternative recipient 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. Writing through a connected AI application requires the separate critical “Prepare shipping packages” capability, which is initially off. Other shipping or packing permissions do not replace it. Reading and writing require data reading permission, full customer data access, and the connected person’s warehouse and order viewing rights; writing additionally requires warehouse booking permission and the applicable 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 the platform, even with “Allowed”. Receipt recovery remains 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.

(3) For each action by which the AI application creates or changes data or triggers an operation, the Processor keeps, on behalf of the Customer, a change log with the previous and new values of the changed fields so that the Customer can undo the action – for actions that cannot be undone (for example bookings, changes to shipping settings, permanent deletions, cancellations and operations with effects outside the platform), with the details that make them traceable, for example the booked details, the name and identifiers of a deleted entry or the way and billing decision of a cancellation; it retains the change log for 180 days and deletes it thereafter. Likewise, it processes the requests of the AI application including their preview and deletes them 180 days after the decision or after their expiry, its workflow drafts until they are published or discarded, at the latest until the workflow or the organization is deleted, and the respective previous live version of a workflow before the AI application publishes, activates or deactivates it or the Customer undoes such a publication, which it deletes 180 days after its creation, and earlier together with the workflow or the organization; it processes test sessions and run logs of simulation test runs of the AI application like other test runs until the workflow or the organization is deleted; requests and live versions for which an action is still in the change log are kept until that action is deleted. Details are set out in the privacy policy (Section 10, “AI access”).

(3a) For connection tests under paragraph 2a, requests and action logs contain only the reviewed account and customer assignments, environment and versions, and information about approval, execution and the limited test result. They store no credentials, access tokens or unfiltered provider responses. The retention periods for requests and change logs under paragraph 3 apply. The test cannot be undone; its record is not a permanently current connection status of the account.

(3b) Shipping profile validation under paragraph 2b creates no permanent validation status on the profile or an order and no shipping receipt. When AI access is used, requests, previews and action records may contain the specifically approved recipient and parcel details, profile, account and client references, environment and versions, and approval, execution and limited result information. Credentials, access tokens and unfiltered provider responses are not stored in these records. The retention periods for requests and change logs under paragraph 3 apply. Transmission cannot be undone; a historical test record does not confirm current shipping readiness.

(3c) Package preparation under paragraph 2c and its business change receipts contain the recipient and package details saved at the time, the acting person, timestamp and any change reason. Drafts and historical receipts may therefore also contain names, addresses and other contact details entered. Receipts make changes traceable and allow repeated or unanswered save requests to be resolved. When AI access is used, requests, previews and action records may also contain these details and approval and execution information; the existing retention periods under paragraph 3 apply to these AI requests and action records. The AI receives no shipping credentials. A historical save receipt confirms neither current preparation status nor shipping readiness.

(4) The provider of the AI application is not a sub-processor of the Processor and is not part of Annex 2; this also applies insofar as the AI application creates or changes data or triggers operations. The Customer alone is responsible for the settings in the “AI access” area, including the released data categories, the levels of the switches and the approval of requests, as well as for the legal basis of the transfer, the contractual relationship with the provider including any agreement pursuant to Art. 28 GDPR that may be required, the requirements for a transfer to third countries (Chapter V GDPR) and informing the data subjects.

(5) The Processor processes search queries of the AI application to the Meykt help center via the sub-processor Google listed in Annex 2 (Gemini interface); it first removes email addresses and telephone numbers from the search text insofar as they are recognizable as such.

(6) The Customer can disconnect connections and switch off AI access at any time; in doing so, the Processor discards the open requests of the connections concerned. The Processor has no influence on data that the AI application has retrieved up to that point. The Customer 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. What the AI application has caused outside the platform, for example sent emails or handovers and messages to other organizations, cannot be taken back.

(7) If the AI application, within the released scope, initiates an operation in which the Processor discloses data – for example emails via an email sending profile of the Customer or via the sub-processor Resend, handovers and messages to production partners or clients (§ 6a), content of processes to their participants, status messages to target addresses stored by the Customer or commands to the Meykt Agent –, the same applies as for the same operation in the platform; the Processor does not engage any further sub-processor for this. The Processor vectorizes images at the instigation of the AI application only in accordance with § 11(3), only with the consent described there, which the connected user has given themselves in the platform and saved for the current version – the AI application cannot give it –, and only after approval by the Customer. The Processor handles bug reports and feature requests that the AI application sends to it like support requests from the platform.

§ 7 Obligations of the Customer

The Customer remains the controller within the meaning of the GDPR. The Customer is responsible in particular for:

• the lawfulness of the processing, including the legal bases for the transfers it initiates
• fulfilling information obligations towards data subjects
• safeguarding data subject rights
• assigning and reviewing roles and permissions
• the permissible configuration of integrations, workflows and machine controls
• compliance with employment law, product safety and data protection requirements in its own production environment
• verifying whether special categories of personal data (Art. 9 GDPR) may be processed before such data is entered into the platform

§ 8 Confidentiality

The Processor ensures that the persons authorized to process the personal data have committed themselves to confidentiality or are subject to an appropriate statutory obligation of secrecy. The confidentiality obligation continues to apply after the respective activity has ended.

§ 9 Technical and organizational measures

(1) The Processor implements the technical and organizational measures described in Annex 1 pursuant to Art. 32 GDPR and maintains them for the term of this agreement.

(2) The measures are subject to technical progress. The Processor may develop them further and replace them with equivalent or better measures; the level of protection agreed in Annex 1 must not be undercut in doing so. Material changes are documented.

§ 10 Sub-processors

(1) By concluding this agreement, the Customer grants the general written authorization pursuant to Art. 28(2) GDPR for the engagement of the sub-processors listed in Annex 2.

(2) The Processor informs the Customer of any intended addition or replacement of a sub-processor at least four weeks before it takes effect, in text form (e.g. by email to the administrator address stored in the account).

(3) The Customer may object to the intended change on legitimate data protection grounds in text form within 14 days of receipt of the information. In the event of a legitimate objection, the parties endeavour to find a reasonable solution; if no such solution is reached, either party may terminate the affected part of the service, and the Customer may terminate the main agreement, for cause (special termination right).

(4) The Processor imposes on each sub-processor, by way of a contract, the same data protection obligations as set out in this agreement (Art. 28(4) sentence 1 GDPR).

(5) Where a sub-processor fails to fulfil its data protection obligations, the Processor remains fully liable to the Customer for the performance of that sub-processor’s obligations (Art. 28(4) sentence 2 GDPR).

§ 11 Third-country transfers

(1) Personal data is transferred to countries outside the European Union or the European Economic Area only if the requirements of Chapter V GDPR are met (an adequacy decision of the European Commission, appropriate safeguards pursuant to Art. 46 GDPR or a derogation pursuant to Art. 49 GDPR) and only within the scope of the Customer’s documented instructions.

(2) The locations and transfer mechanisms relevant to the individual sub-processors are set out in Annex 2.

(3) A separate arrangement applies to the image vectorization feature: the transfer of the selected image to an external service provider in the USA does not take place on the basis of this agreement but exclusively in accordance with the separate provision in Section 6a of the Terms of Service and the Privacy Policy; these also describe the express consent required before each transfer. This service provider is not part of Annex 2.

(4) Transfers to an AI application connected by the Customer are governed by § 6b; in this respect, the Customer ensures that the requirements of Chapter V GDPR are met.

§ 12 Assistance to the Customer

Taking into account the nature of the processing and the information available to it, the Processor assists the Customer with appropriate technical and organizational measures in:

• responding to requests from data subjects under Chapter III GDPR
• deleting, rectifying, restricting or exporting data
• ensuring the security of processing pursuant to Art. 32 GDPR
• notifying and investigating personal data breaches (Art. 33, 34 GDPR)
• data protection impact assessments and prior consultations (Art. 35, 36 GDPR), where required
• demonstrating compliance with the obligations under Art. 28 GDPR

§ 13 Personal data breaches

(1) The Processor informs the Customer without undue delay after becoming aware of a personal data breach affecting the Customer’s data.

(2) The notification contains, where available, information on the nature of the incident, the categories of data concerned, the approximate categories and approximate number of data subjects concerned, the likely consequences, and the measures taken or proposed to remedy and mitigate the breach. Information may be provided in phases where it is not immediately available.

§ 14 Deletion and return

(1) After the end of the main agreement, the Processor deletes all personal data of the Customer or returns it, at the choice of the Customer. The Customer communicates its choice by the end of the 30-day retention period; if the Customer makes no choice, the data is deleted after that period expires.

(2) Paragraph 1 does not apply to the extent that Union or Member State law requires storage of the personal data.

(3) Return format: during the term and within the retention period, the Customer can retrieve the data themselves at any time through the export feature in the account (Terms of Service, Section 13a): as JSON (JSON Lines, gzip-compressed) with a format description (schema.json) and a list of the stored files with download links (dateien.json). Upon request, the return under paragraph 1 is instead made by the Processor in this format.

(4) Data contained in backups is deleted or overwritten in accordance with the respective backup cycle; until then it is not further processed and remains protected against access.

(5) Confirmation of deletion is provided on request in text form.

§ 15 Evidence and audit rights

(1) The Processor makes available to the Customer all information necessary to demonstrate compliance with the obligations laid down in Art. 28 GDPR.

(2) The Processor allows for and contributes to audits — including inspections — conducted by the Customer or another auditor mandated by the Customer.

(3) Compliance may primarily be demonstrated by current certificates, attestations or audit reports of recognized bodies. If these are insufficient in an individual case, the right to an on-site audit remains unaffected.

(4) Unless there is a specific cause (such as a personal data breach or an order of a supervisory authority), the following applies to audits: no more than one audit per calendar year, announced at least 30 days in advance, conducted during normal business hours and without disproportionate disruption of operations, subject to an appropriate confidentiality agreement; no direct competitor of the Processor may be mandated as auditor. The costs of an audit initiated by the Customer are borne by the Customer.

Annex 1: Technical and organizational measures

Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risks to the rights and freedoms of natural persons, the Processor implements the following technical and organizational measures (Art. 32 GDPR):

1. Encryption (Art. 32(1)(a) GDPR)

• encryption in transit: all connections to the platform are encrypted via HTTPS/TLS
• encryption at rest: data at rest is stored encrypted with the infrastructure providers used
• protection of credentials, tokens and secrets through separate, access-restricted management

2. Confidentiality and access control (Art. 32(1)(b) GDPR)

• role- and permission-based access controls within the platform
• tenant-separated data processing: organization-level data separation, technically enforced at the database level (row-level security)
• authentication via secure session mechanisms
• private file storage; file access only via time-limited, signed retrieval URLs
• access by the Processor’s staff to production data only to the extent required for operation, support or error analysis (need-to-know principle)
• physical access control through the certified data centres of the infrastructure providers used; database and file storage in the Frankfurt am Main region

3. Integrity and traceability

• logging of security-relevant events and changes (audit logs)
• technical validation of file uploads (content checks, type restrictions)
• content security policy and further security headers of the web application

4. Availability, resilience and recoverability (Art. 32(1)(b), (c) GDPR)

• regular backups with restore tests
• operation on redundant, managed infrastructure with monitoring
• documented procedure for restoring the availability of and access to personal data in a timely manner after a physical or technical incident

5. Procedures for regular testing, assessment and evaluation (Art. 32(1)(d) GDPR)

• regular review of the effectiveness of the technical and organizational measures and adaptation to the state of the art
• secure development and deployment processes including code reviews
• separation of development, test and production environments

6. Organizational measures

• confidentiality obligation of all persons authorized to process data (§ 8)
• processing control: contractual commitment of sub-processors pursuant to § 10; processing on instructions pursuant to § 6
• pseudonymization where possible and appropriate for the nature and purpose of the respective processing

7. Own processing facility for image processing

• certain image processing features (e.g. background removal) run, as described in the Privacy Policy, on the Processor’s own hardware within the EU under access-protected operation; intermediate files are deleted automatically after 14 days at the latest

Reservation of changes: The Processor may adapt the measures in this annex to technical progress and replace them with equivalent or better measures. The level of protection described here must not be undercut in doing so.

Annex 2: Sub-processors

The Processor engages the following sub-processors to provide the services. Changes follow the procedure set out in § 10.

The external service provider for the image vectorization feature is not part of this annex; it is exclusively subject to the separate, consent-based provision in Section 6a of the Terms of Service and the Privacy Policy (see § 11(3)).

The providers of AI applications connected by the Customer via AI access (for example Anthropic or OpenAI) are likewise not part of this annex; they are governed by § 6b.

For information only: Paddle is not a subprocessor and is therefore not part of this annex. Once paid plans are activated, Paddle sells the subscription as merchant of record and processes the billing, payment and tax data required for this as an independent controller (see Privacy Policy, Section 12).

Version of this annex: October 12, 2026.

Questions about this agreement are answered by Dumanu GmbH at info@meykt.com.