USPS2 Not Providing Rates

-- url of the page with the problem -- : grandprix-software-central.com/index.php/shopping
-- HikaShop version -- : 6.1.0
-- Joomla version -- : 5.3.3
-- PHP version -- : 8.2.29
-- Browser(s) name and version -- : Firefox 142.0.1
-- Error-message(debug-mod must be tuned on) -- : USPS 2: Failed to retrieve prices.
[] One or more required field(s) are missing from the request, /prices/v3/base-rates-list/search. - -

When trying to migrate from the USPS plugin, which I have used for many years now, to the new USPS2 plugin, I am getting these errors. These only show up if I deactivate the current USPS plugin.

USPS 2: Failed to retrieve prices.
[] One or more required field(s) are missing from the request, /prices/v3/base-rates-list/search. - - 

Warning: Undefined array key "code" in /home/gpsc/public_html/plugins/hikashopshipping/usps2/usps2.php on line 594
Warning: Undefined array key "source" in /home/gpsc/public_html/plugins/hikashopshipping/usps2/usps2.php on line 594
Warning: Trying to access array offset on value of type null in /home/gpsc/public_html/plugins/hikashopshipping/usps2/usps2.php on line 594

nicolas wrote: Hi,
The warning messages indicate that the plugin is receiving from USPS a response without rates. Normally, it should return some error information. However, this is not the case and thus the warnings show up as the plugin tries to get the error message from the response.
So, what this means is that this is something unexpected.
Please activate the "debug" setting of the USPS shipping method. Then, reproduce the issue once.
Then, check the "payment log file" setting of the HikaShop configuration:
www.hikashop.com/support/documentation/5...nfig.html#main_files
It will contain information about the problem which will help us tell you what to do.

nicolas wrote: Regarding the lack of documentation, please understand that this plugin was developed and released only a few months ago. We're still waiting for feedback regarding it as we may need to add extra options or change things around before the plugin is mature enough we can publish a documentation.
Also, USPS is not very informative about what things are in their documentation. Here is a page explaining things about the Account number: elextensions.com/how-to-get-a-usps-account-number/
For the Type, you'll have to check with USPS. They don't explain what it is precisely in their documentation, and I couldn't find information about it online.

Regarding the fact that this plugin is not free, that's because we discovered over time that shipping carriers and payment gateways keep on publishing new APIs. And developing a plugin from scratch each time, without being able to recoup our development cost in the timeframe the plugin is useful is not sustainable.

I have tried with and without my account number and get the same result. Also, adding NONE as an account type (with and without account number) yields the same result.

I get the impression that account number and account type are for shipping label generation, not for getting rates. https://www.youtube.com/watch?v=M86cRyrjwOs

The product that I am testing with has a weight of 4.990 ounces and dimensions of 3.0 x 1.0 x 1.0 inches. These work with the original USPS plugin. I changed the weight to 0.31 lbs, but that did not help.

It is curious that the error message does not appear on the page until I disable the original USPS plugin.

The payment log does not log the parameters of the request each time a set of rates is requested. I would think that it would if there is an error.

09.04.25 15:57:14

Array
(
    [weight] => 0.31187496012851
    [length] => 1
    [width] => 1
    [height] => 3
    [originZIPCode] => 80129
    [destinationZIPCode] => 06074
    [mailClasses] => Array
        (
            [0] => PRIORITY_MAIL_EXPRESS
            [1] => PRIORITY_MAIL
            [2] => USPS_GROUND_ADVANTAGE
        )

    [accountNumber] => ######
)


09.04.25 15:57:14

Array
(
    [apiVersion] => /prices/v3
    [error] => Array
        (
            [code] => 400
            [message] => One or more required field(s) are missing from the request, /prices/v3/base-rates-list/search.
            [errors] => Array
                (
                    [0] => Array
                        (
                            [title] => One or more required field(s) are missing from the request, /prices/v3/base-rates-list/search.
                            [detail] => 
                        )

                )

        )

)

09.04.25 16:16:47

Array
(
    [apiVersion] => /prices/v3
    [error] => Array
        (
            [code] => 400
            [message] => One or more required field(s) are missing from the request, /prices/v3/base-rates-list/search.
            [errors] => Array
                (
                    [0] => Array
                        (
                            [title] => One or more required field(s) are missing from the request, /prices/v3/base-rates-list/search.
                            [detail] => 
                        )

                )

        )

)

I sent an email regarding backend access.

Here's some latest showing up in the payment log. if it helps:

09.04.25 23:16:57

grant_type=client_credentials&client_id=<redacted>&client_secret=<redacted>

09.04.25 23:16:57

Array
(
    [access_token] => <redacted>
    [token_type] => Bearer
    [issued_at] => 1757027816971
    [expires_in] => 28799
    [status] => approved
    [scope] => domestic-prices  oauth2-oidc addresses international-prices  usps:payment_methods openid service-standards-files service-standards locations  usps:MIDs shipments
    [issuer] => https://keyc.usps.com/realms/USPS
    [client_id] => <redacted>
    [application_name] => LisanoEntUSPS
    [api_products] => [Public Access I]
    [public_key] => <redacted>
)


09.04.25 23:16:57

Array
(
    [weight] => 0.31
    [length] => 1
    [width] => 1
    [height] => 3
    [originZIPCode] => 80129
    [destinationZIPCode] => 06074
    [mailClasses] => Array
        (
            [0] => PRIORITY_MAIL_EXPRESS
            [1] => PRIORITY_MAIL
            [2] => USPS_GROUND_ADVANTAGE
        )

)


09.04.25 23:16:57

Array
(
    [apiVersion] => /prices/v3
    [error] => Array
        (
            [code] => 400
            [message] => One or more required field(s) are missing from the request, /prices/v3/base-rates-list/search.
            [errors] => Array
                (
                    [0] => Array
                        (
                            [title] => One or more required field(s) are missing from the request, /prices/v3/base-rates-list/search.
                            [detail] => 
                        )

                )

        )

)

I have the updated plugin installed. I could not find information on the "Rate Indicator" or "Entry Facility Type" in the USPS Publication 205 .

Running into this error:

USPS 2: Failed to retrieve prices.
[400] Could not find working sku from SSF ingredients
Could not find working sku from SSF ingredientsUSPS 2: Failed to retrieve prices.
[400] Could not find working sku from SSF ingredients
Could not find working sku from SSF ingredientsUSPS 2: Failed to retrieve prices.
[400] Could not find working sku from SSF ingredients
Could not find working sku from SSF ingredients

09.08.25 16:46:42

Array
(
    [apiVersion] => /prices/v3
    [error] => Array
        (
            [code] => 400
            [message] => OASValidation OpenAPI-Spec-Validation-Domestic-Prices with resource oas://domestic-prices-v3.yaml: failed with reason: [ERROR - [Path '/destinationEntryFacilityType'] Instance value (null) not found in enum (possible values: [NONE,DESTINATION_NETWORK_DISTRIBUTION_CENTER,DESTINATION_SECTIONAL_CENTER_FACILITY,DESTINATION_DELIVERY_UNIT,DESTINATION_SERVICE_HUB]): [], ERROR - [Path '/destinationEntryFacilityType'] Instance type (null) does not match any allowed primitive type (allowed: [string]): [], ERROR - [Path '/priceType'] Instance value (null) not found in enum (possible values: [RETAIL,COMMERCIAL,CONTRACT,NSA]): [], ERROR - [Path '/priceType'] Instance type (null) does not match any allowed primitive type (allowed: [string]): [], ERROR - [Path '/processingCategory'] Instance value (null) not found in enum (possible values: [LETTERS,FLATS,MACHINABLE,IRREGULAR,NON_MACHINABLE,NONSTANDARD]): [], ERROR - [Path '/processingCategory'] Instance type (null) does not match any allowed primitive type (allowed: [string]): [], ERROR - [Path '/rateIndicator'] Instance value (null) not found in enum (possible values: [3D,3N,3R,5D,BA,BB,BM,C1,C2,C3,C4,C5,CP,CM,DC,DE,DF,DN,DR,E4,E6,E7,FA,FB,FE,FP,FS,LC,LF,LL,LO,LS,NP,O1,O2,O3,O4,O5,O6,O7,OS,P5,P6,P7,P8,P9,Q6,Q7,Q8,Q9,Q0,PA,PL,PM,PR,SB,SN,SP,SR]): [], ERROR - [Path '/rateIndicator'] Instance type (null) does not match any allowed primitive type (allowed: [string]): []]
            [errors] => Array
                (
                    [0] => Array
                        (
                            [title] => OASValidation OpenAPI-Spec-Validation-Domestic-Prices with resource "oas://domestic-prices-v3.yaml": failed with reason: "[ERROR - [Path '/destinationEntryFacilityType'] Instance value (null) not found in enum (possible values: ["NONE","DESTINATION_NETWORK_DISTRIBUTION_CENTER","DESTINATION_SECTIONAL_CENTER_FACILITY","DESTINATION_DELIVERY_UNIT","DESTINATION_SERVICE_HUB"]): [], ERROR - [Path '/destinationEntryFacilityType'] Instance type (null) does not match any allowed primitive type (allowed: ["string"]): [], ERROR - [Path '/priceType'] Instance value (null) not found in enum (possible values: ["RETAIL","COMMERCIAL","CONTRACT","NSA"]): [], ERROR - [Path '/priceType'] Instance type (null) does not match any allowed primitive type (allowed: ["string"]): [], ERROR - [Path '/processingCategory'] Instance value (null) not found in enum (possible values: ["LETTERS","FLATS","MACHINABLE","IRREGULAR","NON_MACHINABLE","NONSTANDARD"]): [], ERROR - [Path '/processingCategory'] Instance type (null) does not match any allowed primitive type (allowed: ["string"]): [], ERROR - [Path '/rateIndicator'] Instance value (null) not found in enum (possible values: ["3D","3N","3R","5D","BA","BB","BM","C1","C2","C3","C4","C5","CP","CM","DC","DE","DF","DN","DR","E4","E6","E7","FA","FB","FE","FP","FS","LC","LF","LL","LO","LS","NP","O1","O2","O3","O4","O5","O6","O7","OS","P5","P6","P7","P8","P9","Q6","Q7","Q8","Q9","Q0","PA","PL","PM","PR","SB","SN","SP","SR"]): [], ERROR - [Path '/rateIndicator'] Instance type (null) does not match any allowed primitive type (allowed: ["string"]): []]"
                            [detail] => 
                        )

                )

        )

)

nicolas wrote: Regarding the rate indicator, I do not know what should be an appropriate value for what you're shipping. In your link of the USPS publication 205, check page 114 and following pages. You can see tables of accepted rate indicators for each mail class and processing category.
On my end, I've used "Dimensional Rectangular" as it seems like the most logical for most people and services and it seemed to work fine. However, I'm not sure why "Dimensional Rectangular" or "Single Piece" would be appropriate and I couldn't find precise information about each rate indicator on the USPS website.

nicolas wrote: The "Entry Facility Type" depends on how you ship your goods with USPS. Do they come to your place to pickup the packages ? Do you drive to one of their facility to ship your packages ? Is it a hub, a network distribution center or a sectional center facility ? Do you have another type of arrangement ?

USPS 2: Failed to retrieve prices.
[400] Could not find working sku from SSF ingredients
Could not find working sku from SSF ingredientsUSPS 2: Failed to retrieve prices.
[400] Could not find working sku from SSF ingredients
Could not find working sku from SSF ingredientsUSPS 2: Failed to retrieve prices.
[400] Could not find working sku from SSF ingredients
Could not find working sku from SSF ingredients

I'm having the same issues as you, GPRaceman, and need a similar setup.

However, I'm still not getting any results, regardless of the configuration I've tried.

gpraceman - I'm curious, have you entered a USPS Account Number? That's the one thing I'm still waiting to get.

I, too, am trying to get this to work, and I have yet to receive a rate returned.

I've updated to the latest version but the only thing in my log so far is

Array
(
    [apiVersion] => /prices/v3
    [error] => Array
        (
            [code] => 400
            [message] => One or more required field(s) are missing from the request, /prices/v3/base-rates-list/search.
            [errors] => Array
                (
                    [0] => Array
                        (
                            [title] => One or more required field(s) are missing from the request, /prices/v3/base-rates-list/search.
                            [detail] => 
                        )

                )

        )

)

jazzmang,

In addition to my Client ID and Client Secret, these are the settings that I am running with:

USPS Account Type: None
USPS Account Number: Left blank
Postal Code: <your Zip Code>
Shipping services: Ground Advantage, Priority Mail, Priority Mail Express, and the International options
Processing Category: Machinable
Rate Indicator: Single Piece
Entry Facility Type: None
Price Type: Commercial
Group Packages: Yes
Weight approximation: 10
Dimension approximation: 10
Sort shipping services: Cheapest
Has non standard characteristics: No
Debug: Yes (for now)

This gets us rates pretty close to what we get from Pirate Ship , which is what we use to generate the shipping labels. Most of our shipping is in padded bubble envelopes and USPS Priority Flat Rate boxes. We give the packages to our postman or drop off at the local Post Office.

I see part of the problem now.

Many of our products don't have dimensions set and only have a weight.

Some fit in an envelope, some don't.

If I use a product with all three dimensions set, it works as selected (retail or commercial)

The Weight approximation and Dimensions approximation appear to have no impact, so I'm unsure what they are or what format the dimensions would be in over those without.

Note also that if you have any of the old USPS methods published, you will NOT see errors for the new USPS 2 plugin/methods. The two apparently do play together well for debugging/testing purposes.

jazzmang wrote: I see part of the problem now.

Many of our products don't have dimensions set and only have a weight.

Some fit in an envelope, some don't.

If I use a product with all three dimensions set, it works as selected (retail or commercial)

The Weight approximation and Dimensions approximation appear to have no impact, so I'm unsure what they are or what format the dimensions would be in over those without.

Note also that if you have any of the old USPS methods published, you will NOT see errors for the new USPS 2 plugin/methods. The two apparently do play together well for debugging/testing purposes.

Where does tit say the plugin's Dimension Approximation is a % additional volume factor? There is currently no documentation for the HikaShop plugin. Are you just assuming from the old plugin?

The issue I have is that the USPS postcalc.usps.com/ rate lookup for packages doesn't require LxWxH; you can still enter just the weight and receive the same rates without entering any volume or dimensions for packages.

It will result in the same rates, even if I enter any values for LWH in HikaShop, as long as the total is under one cubic foot.

From what I can find, it appears to be required between not zero but under one cubic foot, at least for Priority Mail and USPS Ground Advantage. However, I see results for pretty much all the other delivery options on postcalc.usps.com without specifying dimensions.

It's always been this way as long as I can remember (a decade or more at this point).

The USPS is still making a basic cubic volume when no dimensions are given, just as before, with the old USPS plugin in HikaShop, as I receive the same rates (retail-wise) based on source zip, destination zip, and weight alone.

In the old HikaShop plugin, I believe this was achieved by setting "Use product dimension" to Off. I guess that either HikaShop or USPS then sets the default dimension for packages or a cubic volume under the old plugin. I'm not sure which side it was happening on, however.

Ideally, what's still needed to be allowed for in the new USPS 2 plugin, as by USPS's own rate lookup is still possible.

Alternatively, allowing setting a set of default dimensions (LWH) in the plugin's settings would complicate the same thing, I suppose.

We use a mix of about 7 HikaShop USPS (old) shipping methods to cover the gamut of product sizes, shapes, and weights we have to deal with. Some have "Use product dimension" to Off, and others have it On. It greatly depends on the type of product, which is why having this flexibility is important, as not everything fits in a standard rectangular box.

Obviously, USPS wants it to work this way, as they allow it on their own site, even though the API itself states that LWH is required for this specific API being used.

I haven't found in the USPS documentation for their APIs that states one way or the other, other than most indicate that LWH are required variables.

jazzmang wrote: Where does tit say the plugin's Dimension Approximation is a % additional volume factor? There is currently no documentation for the HikaShop plugin. Are you just assuming from the old plugin?

The issue I have is that the USPS postcalc.usps.com/ rate lookup for packages doesn't require LxWxH; you can still enter just the weight and receive the same rates without entering any volume or dimensions for packages.

It will result in the same rates, even if I enter any values for LWH in HikaShop, as long as the total is under one cubic foot.

From what I can find, it appears to be required between not zero but under one cubic foot, at least for Priority Mail and USPS Ground Advantage. However, I see results for pretty much all the other delivery options on postcalc.usps.com without specifying dimensions.

It's always been this way as long as I can remember (a decade or more at this point).

The USPS is still making a basic cubic volume when no dimensions are given, just as before, with the old USPS plugin in HikaShop, as I receive the same rates (retail-wise) based on source zip, destination zip, and weight alone.

In the old HikaShop plugin, I believe this was achieved by setting "Use product dimension" to Off. I guess that either HikaShop or USPS then sets the default dimension for packages or a cubic volume under the old plugin. I'm not sure which side it was happening on, however.

Ideally, what's still needed to be allowed for in the new USPS 2 plugin, as by USPS's own rate lookup is still possible.

Alternatively, allowing setting a set of default dimensions (LWH) in the plugin's settings would complicate the same thing, I suppose.

We use a mix of about 7 HikaShop USPS (old) shipping methods to cover the gamut of product sizes, shapes, and weights we have to deal with. Some have "Use product dimension" to Off, and others have it On. It greatly depends on the type of product, which is why having this flexibility is important, as not everything fits in a standard rectangular box.

Obviously, USPS wants it to work this way, as they allow it on their own site, even though the API itself states that LWH is required for this specific API being used.

I haven't found in the USPS documentation for their APIs that states one way or the other, other than most indicate that LWH are required variables.