Good afternoon,
You are receiving this email because it has recently come to CPSC's attention that some of our eFiling Product Registry users are unclear on the expectations surrounding correct usage of some aspects of the registry application, so we are reaching out to provide guidance on several important topics proactively.
In addition to the information provided below, we would also like to make you aware that the Product Registry (and API) will be unavailable this Saturday, July 11th from approximately 7AM to 2PM Eastern Daylight Time (EDT) for scheduled maintenance.
Trade Parties
Within the context of the Product Registry, the term "trade party" refers to a stored entry of Manufacturer, Laboratory or Point of Contact information that has been added within a Business Account for use on certificates of conformity. When adding a trade party, it is required that users provide a single, unique identifier that can be used to reference that trade party's information in the future. This identifier can be either a Global Location Number (GLN) —a unique identifier assigned by GS1—or an Alternate ID, which can be any custom string chosen by the uploading user.
Below are several important pieces of trade party guidance that CPSC would like to clarify:
-
Do not duplicate trade parties: CPSC's expectation is that once all of a trade party's information has been added to a Business Account, that same trade party should not be added again (with the exception of copies made to ensure privacy across different product collections utilizing the Trade Party Privacy feature). Creating multiple copies of the same trade party can have a negative impact on the performance of your Product Registry account and can also present long-term data management challenges. Once a trade party's information has been entered, that entry should be reused for as long as it is accurate, by referencing the trade party's unique identifier in all further certificate uploads and not specifying that this is a new trade party in the upload content. Do not generate a new unique ID for the same trade party information - this explicitly violates the intended use of Trade Parties within the registry and will likely be enforced in a later update with a rejection of that row of data. If a trade party's information changes, users should create a new trade party entry, with a new unique identifier for use with subsequent certificates. Please be advised that the creation of large numbers of unnecessary duplicate trade parties could result in account suspension by CPSC.
-
Reference the existing CPSC-Accepted lab list: CPSC-Accepted laboratories should never be added to the Product Registry by users. If a user incorrectly adds a CPSC-Accepted lab using the lab type code "LAB", that lab will not be recognized on a certificate of compliance as being an Independent Third-Party Laboratory (ITL). Additionally, when referencing a CPSC-Accepted lab, only the lab's 4-digit CPSC ID should be provided; address and contact information are not required. You can view/download a list of all CPSC-Accepted labs at https://cpsc.gov/cgi-bin/LabSearch. We hope to make an API endpoint available to return this information to integrated software in the near future but are not able to provide a date for the expected implementation of that feature at this point in time. Users should never designate CPSC-Accepted ITL laboratory information as a new trade party—this explicitly violates the intended use of laboratories within the registry and will likely be enforced in a later update with a rejection of that row of data.
-
Use duplicate lab records correctly: The intended use of a laboratory test sub-record within a certificate is that each laboratory will refer to all citations tested by that laboratory. The Product Registry was enhanced early this year to enable the supply of component tests wherein a specific laboratory has tested multiple components of a product against the same citations and may therefore be listed multiple times. We have supplied an optional but recommended flag to indicate that a laboratory test sub-record is a component test. Other than component tests, there is no expectation or need for a laboratory to appear multiple times on a certificate. CPSC may choose to implement further validations of the proper use of laboratory records in the future.
Certificate Versioning
The registry allows users to "stack" different certificate versions on top of each other for the same Primary Product ID by using the "update" option. This feature is intended to accommodate the periodic retesting and recertification of products. By linking all versions together, a single product's certificate history is readily accessible in one coherent "chain", allowing CPSC to more efficiently understand the history of the product and thus more effectively coordinate with importers, while also creating a more manageable user experience in the Product Registry user interface.
In cases where users are not providing updated certifications/recertification on an existing certificate, they are not expected to use the certificate update feature and can instead opt to create new certificates. When taking this approach, these certificates will not be recognized as sharing a common history and in the Product Registry will appear as separate items in the default collection view, even if they are for the same product. A typical example where separate certificates would be expected is a single product that is produced at multiple different manufacturers and thus each product-manufacturer combination requires separate certification. CPSC may implement additional reviews and validations on certificate versions in the future.
Use of getImportStatus and getImportLog API Endpoints
It has come to our attention that there is some confusion about how certificate import status can be retrieved through the Product Registry API, compounded by unclear message responses from the API. The getImportStatus endpoint is intended to inform you about the processing state of an import (in progress vs. complete). getImportStatus does not provide insight into the success or failure or error states for individual certificates. If getImportStatus indicates status "Complete" with the message "A problem was encountered during the certificate import process", it indicates that at least one of your certificates was not able to be imported. Regardless, your software should always call the getImportLog endpoint once the getImportStatus endpoint reports completion of the import.
The getImportLog endpoint is the only source of truth for getting the status of individual certificate records associated with an upload. In the event of an error, a certificate will not be accepted to the registry and getImportLog will provide any relevant error codes or messages. Valid records will be imported and stored in the registry. Any integrated software should handle errors for each row such that they can surface the errors through logs (or a user interface) for review and eventual retry when the data issues are corrected. We recognize that the messaging that gets sent back from the getImportStatus endpoint may not be sufficiently clear, and we will look into updating this in a future application patch.
Note that there is currently a short lag after an import has been initiated when getImportStatus may not respond with a valid status. We recommend waiting at least two seconds after initiating an import before calling getImportStatus. Please do not call getImportStatus with excessive frequency—there should be no reason to check an individual upload status more frequently than every 2 seconds for a small upload and longer if your uploads are larger.
General
- Please make sure that you only provide certificate data in the English language, per the requirement stated in the Final Rule. Accordingly, do not include non-Latin characters in any data added to the Product Registry.
- Please avoid sending duplicate invitations when inviting trade partners to collaborate. We plan to roll out invitation management features in the near future, but at the current time, sending multiple copies of the same invitation to a user can in some cases prevent that user from seeing your invitation.
- The Product Registry API currently enforces a 5,000-character limit per certificate which, within the voluntary period, has been sufficient and not posed challenges for existing users. Properly formatted certificates that use trade party unique ID references, ITL lab references, and that do not include duplication of information have, to date, not tested this limit. At this time, you will receive an error message for a row of data > 5,000 characters from getImportLog and that row will not be imported. We can revisit this limit in the future if needed.
- The Product Registry API and CSV Upload have been optimized to handle bulk uploads of certificates in quantities ranging up to and beyond ten thousand products (larger uploads are possible but not recommended). If you are uploading large quantities of certificates, we encourage you to batch the certificates for the most efficient interaction. As noted above, your systems and processes must handle the record-level error responses from getImportLog API or through the CSV Upload Review process.
- The Product Registry API currently implements rate limiting restrictions limiting interactions to five (5) per second. The API at this time is NOT intended for real time integration into your application user experience, but to support synchronization and batch interactions between your system and the Product Registry.
Most of the above guidance applies across all methods of data entry, including API, CSV, and the user interface. Additional information related to these processes, including examples, can be found in the API Specifications document, the User Guide for CSV Upload, and the Product Registry User Guide, all of which are available for download in the eFiling Document Library.
If you have any questions or concerns about any of the above information, please do not hesitate to reach out to the eFiling support team at EFilingSupport@cpsc.gov. However, please note that our support team is dealing with extremely high volumes of inquiries at the moment, so responses may be delayed.
