Guide chapters
GPSR: Product Safety in Practice
The General Product Safety Regulation (GPSR) applies from 13 December 2024 to consumer products offered in the course of a commercial activity, unless sector-specific rules govern the relevant risk. A trader or other entity acting in a commercial capacity is not exempt merely because the product is handmade, turnover is low, or the model is dropshipping. A small manufacturer may keep simpler documentation proportionate to the risk, but the product must still be safe and identifiable. Purely occasional consumer-to-consumer sales are a separate case described above.
What the operator must ensure - and how to do it in an MVP#
The law describes functions, not the number of forms, tables, or panels. For a small marketplace, the minimum implementation looks like this:
- Contact point for authorities. A separate 'for authorities' application is not required. A publicly indicated email address or a form allowing direct communication, not requiring an account, is sufficient. The simplest approach is to create an alias like legal@... or safety@..., which forwards to an existing inbox/ticketing system, and a category 'Public Authority - Product Safety'. This contact point's details must be provided during platform registration on the Safety Gate portal and kept up-to-date.
- Contact point for consumers. This can be the current Artovni support form. A second page does not need to be built. In the 'Report Type' field, a visible option 'Product Safety / Dangerous Product' should be added, and next to the form, an email address or another communication channel allowing contact with a human should be provided. Communication cannot rely solely on a bot.
- Separation of paths, not systems. Authorities and consumers can be directed to the same table and the same team. Category, priority, and deadline allow for service separation. 'Separate point' means a recognizable destination and appropriate message routing, not necessarily separate code or database.
- Safety Gate registration and message reception. Initially, a designated person checking the inbox and portal daily on business days, and a deputy for absences, is sufficient. API integration and automatic offer matching are solutions for larger scale operations, not a starting requirement.
- Information in the offer. The product form should accept and display only the GPSR-required data for the specific product: manufacturer, EU responsible person, identification, and existing safety warnings/information. A universal form with hundreds of fields should not be created.
- Case reception. The current form is sufficient after adding a case type and the ability to provide a link or offer/product identifier, risk description, contact details, and an attachment. If the data can be entered in the description field, separate fields do not need to be created immediately; it is important that the team can identify the product and assess the risk.
- Case recording. A dedicated 'safety panel' is not required. An existing case record can serve as a GPSR case if it retains the content, attachments, product/offer, seller, time of receipt, status, deadline, decision, communication, and actions taken. Access must be restricted to authorized personnel.
- Case identifier. A UUID assigned to each request is a sufficient operational identifier. GPSR does not mandate a case number format. It is advisable to display this UUID or a shorter number in the email confirmation so that the reporter and support staff refer to the same case.
- Blocking and searching for similar offers. In an MVP, changing the offer status to blocked and manually searching for other offers by manufacturer, name, photo, code, or seller is sufficient. Automatic similarity detection is only needed when manual checks prevent meeting deadlines or an order requires proportional searching of identical content.
- Identifying buyers. A second 'buyer list' does not need to be stored. It is sufficient if, from order positions, one can search for individuals who purchased a specific offer/product/batch, export the results, and send notifications. If batches are not used, searching is done by product or offer identifier.
- Cooperation and withdrawal. A brief instruction is needed: who blocks the offer, who responds to the authority, who determines the scope of buyers, who sends the notification, and who closes the case. This can be a one-page procedure and message templates, not a separate workflow module.
Deadlines that the platform must adopt as SLA#
| Event | Maximum legal/operational deadline | Platform rule |
|---|---|---|
| Authority order: removal, deactivation, or warning | without undue delay, no later than 2 business days | Mark as critical; in MVP, an employee can do this after reading the inbox. Execute on the same day if technically possible. |
| Product safety notification | without undue delay, no later than 3 business days | Initial assessment and, if the risk is credible, temporary blocking within 24 hours; full response within the deadline. Automatic escalation is not mandatory if the manual queue is consistently managed. |
| Own credible information about danger | do not wait for an order | Block sales, secure evidence, determine scope, and initiate escalation. |
| Buyer notification/recall | without undue delay after risk confirmation | Direct notification, visible, and not reducing the matter to a regular newsletter. |
How a case should proceed#
- Accept the signal. The existing request UUID is its identifier; do not create a second number if the current one is persistent and searchable.
- Temporarily block the offer if the risk may affect health or safety.
- Identify identical products, variants, batches, other sellers, and all orders.
- Secure offer content, evidence, correspondence, and product data.
- Request documents and responses from the seller/manufacturer within a short deadline that does not violate the operator's deadline.
- Check Safety Gate and communications from relevant authorities.
- Make a documented decision: reinstatement, correction, permanent blocking, warning, or withdrawal.
- Notify the authority and consumers when required; monitor the implementation of the corrective measure.
- Block re-listing and use the case to audit similar products.
Artisan and ceramic mug#
An artisan who makes a mug and sells it under their own name or brand is considered the manufacturer. They must, among other things:
- design and manufacture a product that is safe under normal and foreseeable use;
- conduct and retain a risk assessment and adequate technical documentation;
- enable identification of the product/batch and manufacturer;
- provide warnings and instructions if necessary;
- respond to complaints, incidents, and dangerous products;
- for food contact cups, also comply with food contact material regulations, including substance migration.
The platform does not require documentation created for a factory from a craftsperson, but requires real proof corresponding to the product and risk. The declaration "handmade" itself is not proof of safety.
Dropshipping#
Dropshipping is a logistics method, not a legal exemption. The platform determines:
- who the seller is towards the customer;
- where the goods are located at the time of sale;
- who is the first to bring them into the EU;
- who is the importer and the responsible person in the EU;
- who has the product documents and batch numbers;
- who will carry out the withdrawal and accept the return;
- who will account for packaging, VAT, and customs duties.
Basis and sources: GPSR - consolidated text of Regulation (EU) 2023/988; UOKiK - entrepreneurs' obligations; UOKiK - GPSR questions and answers; European Commission - questions and answers, including on used products; Commission guidelines on the application of GPSR; Safety Gate.
I design multi-vendor platforms with onboarding, payments, moderation, and operational workflows.
Explore marketplace development