Hi,

We recently updated the shopping cart to 7.8.8 last week, things have been fine until today when the UPS shipping method on our site started to have a "Too Many Requests" error. We don't have any modifications related to the UPS API in any way, and USPS and DHL look to work perfectly fine (As we've had a large number of USPS orders as a result of this). Is this something potentially related to UPS servers?

-Zach C.

It also looks to not happen to everyone, or at least hasn't happened 100% of the time, as we've had a couple of UPS orders come through earlier today.

-Zach C.

Hi, we’re seeing this issue on our website today (2025-11-03), and also on several other ECT sites.

Checking UPS rates on our sites returns the message "Too Many Requests".

As a result, no orders have been processed since yesterday.

ServeLink support verified that UPS is explicitly rejecting requests from our server to the Rate API — so this appears to be a UPS-side problem.

Does anyone have a reliable contact at UPS who can help escalate or resolve this?

thank God I am not the only one...
My rep says there are no outages
I have tried everything I can think of.

Up until about 10:30 am eastern it was fine.

My rep is working on getting me a contact for support.

David

my rep just responded with tech support #877-289-6418

It's a bit concerning that I checked several random online stores that use UPS but not the ECT cart — and none of them showed any issues.

Would appreciate it if others could share what they find.

They are telling me we are not on Oauth2 when I know I am...

Ok, after bouncing me around on the phone, - they gave me a different number for API help - 800-247-9305 option 3 then 2

The guy I spoke to just sent me an email asking for details of my site, but also had this

quote:

---

Welcome to UPS API Support.

There is a limit to the number of API calls you can make at once. UPS sets a maximum number of requests per minute for each user. If you exceed these limits, you’ll receive an error message “429 - Too Many Requests” in the response.

You will also receive a 429 error if you request a new OAuth token with each call. The token expiration time is returned in the response. Please avoid requesting a new token with each call and only refresh it shortly before expiry.

The rate limits in the testing environment are lower than those in the production environment. However, you should be able to test your API without exceeding the limit.

Breaking down API calls over time can help prevent 429 errors. Techniques include using pagination to retrieve data in smaller chunks, scheduling requests based on time, and utilizing API monitoring tools to track call volumes and response times at different intervals.

For further assistance, I can escalate the issue to our team that handles 429 - Too Many Requests support. I'll need the following information:

---

FWIW, here's the full text of the latest trouble ticket reponse from ServeLink, who seem to have provided as much help as they possibly can:

============

"I have reproduced this on various servers, various operating systems, on Windows Server too. Including on servers that don't do anything with UPS at all. It would seem possible from that, that they are blocking our IP block that you are housed on here 204.140.21.0/24, but I just tried another server of ours in a different part of the country, different IP block, never made a call to UPS in its life and the same result; "too many requests". If one request is too many there is little hope for you.

I actually get the same response if I try and simulate the cURL request to UPS from my laptop, which is also nowhere near your server. Sorry, this is down to UPS and Akamai who are running their edge services for them."

============

ETA: Since this issue seems to appear on ECT PHP/ASP stores—across different webhosts—but not on stores with different carts I've checked, I’d appreciate it if the ECT development team could weigh in with possible troubleshooting steps.

Note that we updated to v7.8.8 more than a week ago, and the UPS issue only appeared today, so that update doesn’t appear to be the cause.

Thanks for sharing that Paul.
I have emailed Vince so he will be aware.
David

Hi All
Sorry to hear you are having problems, but from the UPS response...

quote:

---

You will also receive a 429 error if you request a new OAuth token with each call. The token expiration time is returned in the response. Please avoid requesting a new token with each call and only refresh it shortly before expiry.

---

I've tested this and it's not the case. We are correctly using the expiration time to enable us to reuse the same OAuth token until it times out.

quote:

---

For further assistance, I can escalate the issue to our team that handles 429 - Too Many Requests support. I'll need the following information:

---

Could you please let me know what that information is they are looking for?

Vince

Click Here for Shopping Cart Software
Click Here to sign up for our newsletter
Click Here for the latest updater

Hi Vince,
Company Name

Contact Information:
Name:
Email Address:
OAuth Client ID:
User ID:
Each affected API URL:

Additional information:



Thanks!
Jeevan B.
UPS Developer API Support
We are also available through Phone Support - 8002479035 (Option 3 and Sub-option 3)


He was suggesting I was not on Oauth2 and I'm certain I am.
My question is are we hitting the right API url?
with the XML in the URL, he seemed to think I was on the old stuff.

David

FWIW, early-on in their troubleshooting process ServeLink support responded with the following.

If I run a XML rate request manually here's the response:

* About to connect() to onlinetools.ups.com port 443 (#0)
* Trying 23.37.16.254...
* Connected to onlinetools.ups.com (23.37.16.254) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* SSL connection using TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
* Server certificate:
* subject: CN=onlinetools.ups.com,O="United Parcel Service, Inc.",ST=New Jersey,C=US
* start date: Mar 10 00:00:00 2025 GMT
* expire date: Mar 10 23:59:59 2026 GMT
* common name: onlinetools.ups.com
* issuer: CN=COMODO ECC Organization Validation Secure Server CA,O=COMODO CA Limited,L=Salford,ST=Greater Manchester,C=GB
> POST /ups.app/xml/Rate HTTP/1.1
> User-Agent: curl/7.29.0
> Host: onlinetools.ups.com
> Accept: */*
> Content-Type:text/xml
> Content-Length: 1475
> Expect: 100-continue
>
< HTTP/1.1 100 Continue
< Expires: Mon, 03 Nov 2025 18:28:37 GMT
< Cache-Control: max-age=0, no-cache, no-store
< Pragma: no-cache
< ak-grn-1: 0.58a7cb17.1762194517.465bb657
< Strict-Transport-Security: max-age=63072000 ; includeSubDomains ; preload
< HTTP/1.1 429 Too Many Requests
< Content-Type: application/xml
< errorcode: 10429
< errordescription: Too Many Requests
< x-frame-options: DENY
< x-content-type-options: nosniff
< x-xss-protection: 1; mode=block
< Access-Control-Max-Age: 600
< x-request-id: b67fcc5f-ef5f-41ba-bcba-dd164ec71f77
< Content-Length: 342
< Expires: Mon, 03 Nov 2025 18:28:38 GMT
< Cache-Control: max-age=0, no-cache, no-store
< Pragma: no-cache
< Date: Mon, 03 Nov 2025 18:28:38 GMT
< Connection: close
< ak-grn-1: 0.58a7cb17.1762194517.465bb657
< Strict-Transport-Security: max-age=63072000 ; includeSubDomains ; preload
< ak-grn-1: 0.58a7cb17.1762194517.465bb657
< Strict-Transport-Security: max-age=63072000 ; includeSubDomains ; preload
<
* Closing connection 0
<?xmlversion="1.0"?><RatingServiceSelectionResponse><Response><ResponseStatusCode>0</ResponseStatusCode><ResponseStatusDescription>Failure</ResponseStatusDescription><Error><ErrorSeverity>Hard</ErrorSeverity><ErrorCode>10429</ErrorCode><ErrorDescription>Too Many Requests</ErrorDescription></Error></Response></RatingServiceSelectionRespons

Hi David

quote:

---

I've tested this and it's not the case. We are correctly using the expiration time to enable us to reuse the same OAuth token until it times out.

---

I take this back and it does seem that there was a problem with re-using the oAuth token with the ASP version only. But this doesn't explain why the PHP stores are also having problems. The fix is in the inccart.asp file and the changes are around line 28, where the variables are initialized and that's an important fix. But could you give Jeevan my contact details and I'll send him all the information he needs?

Vince

Click Here for Shopping Cart Software
Click Here to sign up for our newsletter
Click Here for the latest updater

What cart version is everyone with this issue as I am wondering is it a version specific problem or a problem in general, I am on v7.8.8


[EDIT]

I just tried one of my ASP sites that is on v7.8.8 and got this notice on the cart page:
There seems to be a problem connecting to the shipping rates server. Please wait a few moments and refresh your browser.
Error, invalid response from https://onlinetools.ups.com/ups.app/xml/Rate (429).


Marshall
CENLYT Productions - ms designs
Affordable Web Design
Custom Ecommerce Designs
Responsive Websites
Cenlyt.com

Hi Marshall, yes you have the issue as well.
It may not be isolated to any version.
Vince is on the case and I will send him the contact I have at UPS

David

Hi David,

I was just curious. If it was only affecting v7.8.8, I could try reinstalling 7.8.7.

Marshall
CENLYT Productions - ms designs
Affordable Web Design
Custom Ecommerce Designs
Responsive Websites
Cenlyt.com

Hi Marshall
It's affecting the old XML integration and the new oAuth integration and ASP and PHP versions as well. It's hard to say still what the cause of this is but I really need to get some feedback from UPS and we're waiting for them to reply.

Vince

Click Here for Shopping Cart Software
Click Here to sign up for our newsletter
Click Here for the latest updater

I created a new API, but the instructions on the UPS admin page has "along with your UPS Account Number" but there is no specific field for that, only UPS Shipper Number.

Also, should UPS Access Key (Only used for legacy connections), which does currently have a number in it, be left alone or should the number be deleted?

And is there a callback URL? I left it blank and UPS did not seem to have a problem with that.

[EDIT]
I tried just using the new Client ID and Client Serect, and deleting the legacy information, and got this "Invalid Authentication Information." when placing an order.

Marshall
CENLYT Productions - ms designs
Affordable Web Design
Custom Ecommerce Designs
Responsive Websites
Cenlyt.com

Hey guys. I know this was already covered, but I just wanted to chime in to confirm V7.6.2 ASP is having issues as well.

Thanks for working on it for us Vince!

Hi All
I've just been contacted by someone using the legacy (XML -> not oAuth / JSON) API and they have been granted an extension to continue using the legacy API until the end of December. So I think that this is part of the issue is that UPS are cracking down on those using the legacy API - THOUGH THOSE ON THE ASP VERSION SHOULD INSTALL THE UPDATES FOR THE oAuth FIX.

quote:

---

I created a new API, but the instructions on the UPS admin page has "along with your UPS Account Number" but there is no specific field for that, only UPS Shipper Number.

---

I believe your UPS Account Number is your Shipper Number.

quote:

---

And is there a callback URL? I left it blank and UPS did not seem to have a problem with that.

---

There is no callback URL.

quote:

---

Also, should UPS Access Key (Only used for legacy connections), which does currently have a number in it, be left alone or should the number be deleted?

---

It just won't be used with the new oAuth API

quote:

---

I tried just using the new Client ID and Client Serect, and deleting the legacy information, and got this "Invalid Authentication Information." when placing an order.

---

Ok, that's not good so do you want to send them to me and I'll try on my test site here.

Vince

Click Here for Shopping Cart Software
Click Here to sign up for our newsletter
Click Here for the latest updater