Can existing users of the XML APIs request an extension to the early June deadline?

[nightcoding2021]

Dear UPS,

It's apparent from this forum that the JSON APIs have some critical problems. It would appear unlikely that UPS will be able to resolve those issues, plus allow end users sufficient time to integrate once you've fixed them, before the early June deadline.

Therefore, please can you provide guidance if existing API users can request extended access to the XML APIs, bearing in mind the huge package volumes involved and the even bigger monetary value contained therein?

Thank you.

[deckberg-quantumdigital]

Yes, the documentation is severely lacking and the does not have full feature parity with the existing API. Also, no mention of SurePost anywhere.

[UPSRahul]

Yes, the documentation is severely lacking and the does not have full feature parity with the existing API. Also, no mention of SurePost anywhere.

Thank you for submitting your concern on the exclusion of Surepost. Use of the UPS Surepost product requires a signed agreement that ensures the customer integration of Surepost complies with UPS guidelines. Under the process today once a signed agreement is in place the Surepost Rate and Ship API supplements are automatically distributed. We will be sure to add this information to our product pages on developer.ups.com

[nightcoding2021]

It's worth mentioning that the XML API is NOT being switched off in July. Only the OAuth authentication is being enforced, so my understanding is users can continue using the XML API until a date as yet unannounced. Looking at the forum posts and the amount of inconsistencies, it seems the JSON API is pretty much in "Beta" testing - with live users (!) Bearing in mind I'd rather make the switch in Q1/Q2 than Q3/Q4 of any given year, I decided to get the JSON shipping live - it's working, but I'm worse off than before for sure.

I haven't integrated the Rating API and noticed some users are reporting inconsistencies at the moment, I'll hold off on that one.

Personally, my view is there is no way any complicated API should be moved to JSON. XML is far more suitable for somewhat more complex use cases and much easier to code with the named end tags and so on. I don't know how other people operate but I'm using Notepad++ to code everything.

[AlexAtPeerless]

Hi @nightcoding2021, I have asked UPS and the XML API has not been/will not be modified to support OAuth, so when the Access keys retire, so does the XML API.
@UPSRahul this is still true, right? (C-0186307138).

[AlexAtPeerless]

Ok anybody following this issue will be interested in this:
https://developer.ups.com/api/reference/steppingstone/endpoints?loc=en_US
Thanks to @deckberg-quantumdigital for commenting about this on closed issue #93 .

[nightcoding2021]

This is what everyone needs... which will probably help out more than a few people! JSON - what a nightmare format for a complex API...!!

WebService/XML API – use your bearer token in a request

• Headers, add the following 2 Key-Value pairs:
• Authorization: Bearer [token, with one space before].
• TransactionSrc: User-Defined,
• transId: 0001.
• URL:
  The URL used to send transactions to UPS with OAuth credentials is different than the URL used for Access Key model. There is an extra api/.
  Please see an example below is based on Tracking API but the rule stay the same with other APIs:
  WS
  • test: https://wwwcie.ups.com/api/webservices/Track
  • production: https://onlinetools.ups.com/api/webservices/Track
    XML
  • test: https://wwwcie.ups.com/api/ups.app/xml/Track
  • production: https://onlinetools.ups.com/api/ups.app/xml/Track

Before, with standard XML/Webservice access key based request we had: https://onlinetools.ups.com/ups.app/xml/Track so as you can see within URL additional “api/” part needs to be added.

Important: Ensure there are no credentials in the request body. As this stepping model contain token request to authorize API call, security container needs to be taken off from the standard request.

[UPSRahul]

Hi,

We understand that the transition to use both OAuth and our RESTful APIs is a lot of technical change. For any users that are unable to make the transition from SOAP/XML to REST APIs, we have introduced a Steppingstone Model. This will allow users to continue using their existing SOAP/XML payloads, while gaining all the benefits of the OAuth 2.0 security pattern. Details on how to utilize the Steppingstone model can be found in the Resources section of the UPS Developer Portal.

[pperetko]

    I have this code that worked all the time.
    How to create a class now to send this token?

     FauthData := uUPSShip_WSDL.UPSSecurity.Create;
      userToken:= uUPSShip_WSDL.UsernameToken.Create;
      userToken.Username:=..........;
      userToken.Password :=............;
      FauthData.UsernameToken:= userToken;
      serviceToken:= uUPSShip_WSDL.ServiceAccessToken.Create;
      serviceToken.AccessLicenseNumber :=Polaczenie.Token;
      FauthData.ServiceAccessToken:= serviceToken;
      request_:= ShipmentRequest.Create;

     (FiServices as ISOAPHeaders).send(FauthData);
   ProcessShipment(request_, nil);