# CPSC Regulatory Updates ## Background International shipments carrying CPSC-regulated consumer products (children's toys and similar goods) need the product's CPSC compliance-certificate data on their **customs documentation**, so it's available to US customs at import — a requirement as of **8 July 2026**. EasyPost's role is on the customs-documentation side only: EasyPost has added fields so you can attach the CPSC certificate identifiers to a shipment's customs items, so the data travels with the shipment. **EasyPost does not file with CPSC or register products on your behalf** — you provide identifiers for a certificate you have already registered with CPSC, and they flow through as part of the shipment's customs data. CPSC recognizes two ways to convey the certificate data: the full certificate data set, or the **Reference method** — where a pre-registered certificate is referenced by just three identifiers (**Certifier ID + Product ID + Version ID**). **EasyPost's support starts with the Reference method, for products already registered with CPSC.** Not-yet-registered products, exemptions, and disclaims are not currently supported. - **Where the data lives — per item.** A single parcel can hold multiple items with different certificates, so CPSC data lives on **`customs_item`**, not at the shipment level. - This guide covers the API fields you send (Part 1) first, then how carriers handle them (Part 2). ## Part 1 — What You Send to EasyPost To file a CPSC-regulated item under the **Reference method**, you supply **three identifiers per item** — the same three CPSC uses to look up your pre-registered certificate: | CPSC-required element | EasyPost `customs_item` field | Notes | | :-------------------- | :------------------------------------------------------------------ | :------------------------------------------------------------- | | **Certifier ID** | `regulatory_info.cpsc.certifier_id` | The certifying company registered in the CPSC Product Registry | | **Product ID** | One of `standardized_product_id`, `code`, `manufacturer_product_id` | Send the product identifiers you have — EasyPost maps them | | **Version ID** | `regulatory_info.cpsc.version_id` | The certificate version | All three live on **`customs_item`** (not the shipment — one parcel can carry multiple regulated items with different certificates) and apply anywhere `customs_items` are accepted: both `/v2/shipments` and `/v2/orders`. > **On the API these fields are optional / nullable — but CPSC generally expects all three to file under the Reference method.** The API won't reject a shipment that omits them, but CPSC may reject the _entry_. Supplying all three is recommended for any CPSC-regulated item. **Full example:** [Content omitted: interactive code examples. Review the rendered documentation for request and response examples.] ### Product ID — the `customs_item` fields Populate whichever of these you have — EasyPost handles mapping them for the carrier. These are the **same fields** that carry the EU product identifiers (see the companion [EU Regulatory Updates](/guides/eu-regulatory-updates-guide) guide) — one set serves both regulatory bodies: | Field | Max len | CPSC Product ID type | Also serves (EU) | | :------------------------ | :------ | :-------------------- | :--------------- | | `standardized_product_id` | 64 | **GTIN** | S-PID (C129) | | `manufacturer_product_id` | 64 | **Model / Alternate** | NS-PID (C128) | | `code` _(existing)_ | — | **SKU** | M-PID (C127) | - **`code` is your existing merchant product ID — keep populating it exactly as you do today.** - Only `manufacturer_product_id` and `standardized_product_id` are new fields. ### Certifier ID & Version ID — the `regulatory_info` object Certifier ID and Version ID are certificate metadata, not product identifiers, so they live in a new **`regulatory_info`** object, **namespaced by regulatory governing body** (`regulatory_info.cpsc`). | Field | Max len | Description | | :---------------------------------- | :------ | :------------------------------------------------------------------------------------------- | | `regulatory_info.cpsc.certifier_id` | 64 | CPSC **Certifier ID** — the certifying company in the CPSC Product Registry | | `regulatory_info.cpsc.version_id` | 64 | CPSC **Version ID** — a specific certificate version; increments on retest / material change | - **Blank values are not persisted** — an empty `cpsc` object collapses to `regulatory_info: null`. - Each field is validated (`max_length: 64`, type `String`). - **Scope:** products **already registered** with CPSC (Reference method). Disclaim / exemption / not-yet-registered paths are not currently supported. ## Part 2 — Carrier-Specific Implications Carrier-specific use of these CPSC fields are being developed on a rolling basis, pending carrier API updates and EasyPost integration with the carrier APIs. In preparation for the individual carrier support, we encourage you to implement these fields now, so that the data will be automatically sent to supported carriers as soon as support is rolled out. **Carrier delivery status (as of Sept, 2026):** | Carrier | Product IDs | CPSC `regulatory_info` | | :------ | :-------------- | :--------------------- | | FedEx | support pending | support pending | | UPS | support pending | support pending | | USPS | support pending | support pending | ### FedEx When CPSC delivery is wired, EasyPost will map the reference-method fields to the FedEx **REST** Ship API, inline at `customsClearanceDetail.commodities[].regulatoryDetails[].referenceMessageSet`: | EasyPost `customs_item` field | FedEx REST field | | :---------------------------------- | :------------------ | | Product ID | `registryProductId` | | `regulatory_info.cpsc.certifier_id` | `certifierId` | | `regulatory_info.cpsc.version_id` | `productVersion` | #### FedEx Web Services / SOAP API **FedEx Web Services / SOAP integration is deprecated - for proper support of CPSC, you should complete steps to migrate your carrier accounts to use the FedEx REST integration** FedEx has not added the CPSC fields to the legacy Web Services / SOAP path, and has announced no plans to do so. If you cannot migrate to REST, the way to convey CPSC data is to pack the three reference identifiers into **each item's description on the commercial invoice**: [Content omitted: interactive code examples. Review the rendered documentation for request and response examples.] Example: `Children's Plastic Toy Car – CPSC REGULATED PRI-TOY-CAR-01 | ACMEAPPAREL | V1.0` ### UPS UPS has not released CPSC support in their API as of Sept, 2026. In anticipation of that support, you should start sending data through the fields documented above. When UPS updates their API, and EasyPost updates the UPS carrier integration, these fields will automatically be sent to UPS without any further changes on your part. ## Summary | Change | Layer | What it does | | :---------------------------------- | :------------- | :------------------------------------------------------------------------------------- | | `standardized_product_id` | API (agnostic) | GTIN product ID on `customs_item` (CPSC Product ID: GTIN; EU S-PID) | | `manufacturer_product_id` | API (agnostic) | Manufacturer product ID on `customs_item` (CPSC Model / Alternate; EU NS-PID) | | `regulatory_info.cpsc.certifier_id` | API (agnostic) | CPSC Certifier ID (Reference method) | | `regulatory_info.cpsc.version_id` | API (agnostic) | CPSC Version ID (Reference method) | | Carrier delivery — product IDs | Carrier | Sending product IDs to carriers on the wire — not yet available | | Carrier delivery — CPSC | Carrier | Sending `regulatory_info.cpsc` to carriers (generic serialization) — not yet available | **Regulatory date:** CPSC eFiling mandatory **July 2026**.