The US Consumer Product Safety Commission (CPSC) Product Registry supports certificate data entry through the user interface, CSV upload and API integration. This article answers common questions regarding trade party management, certificate versioning and upload controls to help organizations improve data quality and support efficient eFiling processes.
As companies prepare for CPSC eFiling requirements and ongoing certificate management obligations, data quality and effective system management are critical. The Product Registry includes specific requirements for managing trade parties, maintaining certificate histories and handling uploads through CSV and API processes. Understanding these requirements can help organizations reduce errors, improve efficiency and support compliance with CPSC expectations.
This article provides general information and does not constitute legal advice. CPSC requirements, guidance, system validations and technical specifications may change. Companies should verify the latest official materials and evaluate how the requirements apply to their products, certification responsibilities and import processes.
Guidance for mail shipments
Q1. Do mail shipments require eFiling, and how should importers prepare?
Answer. Yes. Mail shipments entering the United States under US Customs and Border Protection’s (CBP) new Entry Type 13 process are subject to CPSC eFiling requirements. From October 22, 2026, regulated products imported through international mail must transmit either a Full Message Set or a Reference Message Set through the Automated Commercial Environment (ACE) when a certificate of compliance is required.
Previously, international mail shipments generally could not participate in CPSC eFiling because CBP did not collect the entry information needed to support Partner Government Agency (PGA) data transmission. Entry Type 13 now enables these shipments to participate in the eFiling program through ACE. The importer remains responsible for ensuring that all required certificate information is submitted.
Takeaway: identify products imported through international mail that require a certificate of compliance and confirm brokers, logistics providers and internal compliance teams are prepared to support ACE transmission before the October 22, 2026 implementation date.
Trade parties: build clean, reusable master data
Q2. What is a ‘trade party’ in the Product Registry?
Answer. A trade party is a stored manufacturer, laboratory or point-of-contact entry within a Business Account. The entry can be referenced on certificates of conformity. Each trade party requires one unique identifier: either a Global Location Number (GLN) assigned by GS1 or an Alternate ID selected by the uploading user.
Takeaway: establish standardized naming conventions and unique identifiers for manufacturer records and maintain trade parties as reusable master data rather than creating duplicate entries for each certificate.
Q3. What should be done when a trade party’s information changes?
Answer. Create a new trade party entry with a new unique identifier, then use the new identifier for subsequent certificates. The previous entry remains part of the earlier certificate history; it should not simply be duplicated under a new ID when no information has changed.
Takeaway: maintain documented change-control procedures for updates such as legal name, address or other material identity changes and document the effective date of each revised master data record.
Q4. Should users add a CPSC-accepted laboratory as a new trade party?
Answer. No. CPSC-accepted laboratories should be referenced from the CPSC’s accepted laboratory list rather than created by users. When referencing such a laboratory, provide only its four-digit CPSC ID. Address and contact details are not required for that reference.
If a CPSC-accepted laboratory is incorrectly added using the ‘LAB’ type, it will not be recognized on the certificate as an independent third-party laboratory (ITL).
CPSC has indicated that future validation may reject rows that incorrectly designate CPSC-accepted ITL information as a new trade party.
A list of all CPSC-accepted labs can be downloaded here.
Takeaway: review existing trade party records and remove any CPSC-accepted laboratories created as trade parties, using the laboratories’ official four-digit CPSC IDs instead.
Q5. When may the same laboratory appear multiple times on one certificate?
Answer. A laboratory test sub-record is normally intended to link one laboratory to all citations tested by that laboratory. Repeating the laboratory is appropriate for component testing where the same laboratory tested multiple components against the same citations. An optional, recommended flag can identify the record as a component test. Outside component testing, the same laboratory generally should not appear multiple times.
Takeaway: where possible, citations should be consolidated under a single laboratory record unless a genuine component-testing structure exists, helping to reduce duplication and support more efficient validation.
Certificate versioning: preserve the right history
Q6. What does the certificate ‘update’ option do?
Answer. It stacks certificate versions for the same Primary Product ID into one linked history. This is designed to support periodic retesting and recertification, allowing CPSC and the account user to review the product’s certificate history as one coherent chain.
Takeaway: use the update option for periodic retesting or recertification of an existing product.
Q7. When should a new certificate be created instead of an update?
Answer. If the new submission is not an updated certification or recertification of an existing certificate, a separate certificate may be more appropriate. Separate certificates do not share a common history and appear as separate items in the default Product Registry collection view, even when they concern the same product.
A typical example where separate certificates would be expected is when different manufacturers produce a single product and each product-manufacturer combination requires separate certification. CPSC may implement additional reviews and validations on certificate versions in the future.
Takeaway: create a separate certificate when there is no continuous certificate history, such as when the same product is produced by a different manufacturer.
General controls for reliable uploads
Q8. What language and character rules apply to certificate data?
Answer. Certificate data must be provided in English, consistent with the Final Rule. Non-Latin characters should not be included in data entered into the Product Registry.
Takeaway: add pre-upload validation that checks required text fields for English-language, Latin-character content.
Q9. What is the current certificate size limit in the API?
Answer. The Product Registry API currently applies a 5,000-character limit per certificate. A record exceeding that limit will receive an error message through getImportLog and will not be imported. Proper use of trade party unique ID references, ITL lab references and non-duplicative data helps keep certificate payloads efficient.
Takeaway: calculate payload length before upload and eliminate repeated master data. Route near-limit records for review before submission.
Q10. How should large certificate volumes be uploaded?
Answer. The API and CSV Upload are optimized for bulk uploads ranging up to and beyond 10,000 products, although larger uploads are not recommended. CPSC encourages batching large quantities for more efficient interaction. Processes must still handle record-level errors through getImportLog or the CSV Upload Review process.
Takeaway: use controlled batches sized for traceability and retry, rather than using a single very large transaction. Reconcile accepted and rejected row counts after every batch.
Q11. What rate limit applies, and is the API intended for real-time user interactions?
Answer. The Product Registry API currently limits interactions to five per second. CPSC states that the API is not intended for real-time integration into an application user experience; it is intended to support synchronization and batch interactions between a company system and the Product Registry.
Takeaway: design queued or scheduled synchronization with throttling, backoff and record-level reconciliation rather than synchronous, screen-by-screen submission.
SGS solutions
We support organizations in translating CPSC eFiling requirements into practical operational controls, including certificate data review, testing and certification support, workflow assessment, data field mapping, upload-readiness checks and training for compliance and technical teams. Scope and deliverables should be agreed upon based on the client’s products, certification model and system environment.
Find out more about SGS SMART, our digital platform that supports compliance, data management and supply chain transparency.
References
- Primary basis – CPSC Product Registry operational guidance covering Trade Parties, Certificate Versioning, getImportStatus/getImportLog and general data-entry controls
- Official laboratory reference – CPSC-Accepted Laboratories Search
- Additional CPSC materials – API Specifications, User Guide for CSV Upload and Product Registry User Guide, available through the CPSC eFiling Document Library for field definitions, examples and technical details
Enjoyed this article?
Find more news and updates in our Consumer Compact newsletter >
Delivered direct to your inbox
© SGS Société Générale de Surveillance SA.
