This article is relevant if you are working with NetSuite’s Suitelets and attempting to connect in an Anonymous fashion.
Background
NetSuite’s Suitelet technology, and its close partner, Restlets, are excellent technologies to produce integrations between NetSuite and other internet based systems. Restlets are the preferred approach to send JSON data between NetSuite and third party systems Restlets require user authentication to work. However, there are times that you need anonymous access to NetSuite to expose business data to third parties. This is where Suitelets offer a solution.
If you are developing Suitelet technology, you know that you need to make sure that the Audience is Public by including “All Roles”. Of course, you must also turn on the “Available without Logon” checkbox in the deployment definition.
You may find that things are working as you expect as you test your Suitelet. But then you may find that you encounter funny connection errors.
Suitelet Error: HTTP 405 Method Not Allowed
We kept encountering an HTTP 405 Method Not Allowed error when the Suitelet was working as expected using our favorite JSON posting tool, PostMan.
After a fair amount of trial and error work, an engineer on my team figured out that you need to have a User Agent Header record in the HTTPs request. You may be coming from a server environment that is not supplying this value automatically. To solve this, add the following key/value pair to the HTTP Headers: “User-Agent : Mozilla/5.0”. Now the Suitelet will think that the request is coming from a browser and it should accept the anonymous request.
Addendum
As of September, 2017, We recently discovered that if NO User agent is sent, NetSuite will work. Some server side applications are sending a User-Agent (it may not be obvious) and this causes a problem. We also discovered that NetSuite only lets some specific User-Agents in; I don’t have a valid list but it does mean you may need trial and error techniques to get it dialed in.
Extend NetSuite
Remember, NetSuite is a platform designed to be enhanced to meet business requirements. If you want help extending NetSuite, contact us.
Marty Zigman
Holding all three official certifications, Marty is regarded as the top NetSuite expert and leads a team of senior professionals at Prolecto Resources, Inc. He is a former Deloitte & Touche CPA and has held CTO roles. For over 30 years, Marty has produced leadership in ERP, CRM and eCommerce business systems. Contact Marty to set up a conversation.
More Posts - Website - Twitter - Facebook - LinkedIn - YouTube
Did you guys ever find a way to get around this “limitation”? I’m experiencing the same issue with anonymous Suitelets, but I don’t have control over the HTTP requests, because they come from an external system. I noticed that when the source doesn’t send the User-Agent header, the request gets dropped before it even reaches the script execution flow. Do you guys have any idea how I could overcome this?
Hi Jamie,
Here is what I believe you can do. If you have the Site Builder web site, you can activate SuiteScript Server Pages. With this technology, I have been able to produce and receive anonymous server based callbacks that do not require that header setting.
Marty
Hi Marty,
Thanks for the SSP tip.
I’ve actually been dealing with this since sometime in 2009. FWIW I operate a proxy for a number of customers who, like Jamie, cannot alter the request headers.
The other use it has is that some external systems cannot POST to a url with query parameters. The proxy handles that case as well.
Hey Brett,
That’s very cool. I wonder if you could setup a general service for this. Yet, it needs to be trusted because credentials are on the wire. Any thoughts on publishing more about it?
Marty
Hi Marty,
Actually the credentials are not on the wire because this is specifically for anonymous suitelets.
If you are doing machine to machine you can use a RESTLet which doesn’t have the User-Agent issue but does require a valid Netsuite login.
A general service could be set up but the configuration for this is pretty trivial so hasn’t been necessary.
Right, of course. This is a SuiteLet so it doesn’t require a credential. I wonder if it makes sense to produce a simple Java servlet or Python script to the general NetSuite community to solve this. Ideally, NetSuite would resolve it so we don’t have do this intermediate step.
Well because this ends up being proxy the code needs to be fairly capable. I put the servlet I have together by piecing together tips from a number of sources. I’d be happy to put that up on github if anyone actually wants to use it. Also as mentioned above I do host this as a service for $180/year.
I am facing exactly the same issue and I do not have the control over the http header either. But the external application does send it’s own user-agent header, say “ABC/2.0” . This returns a 405 error. Is there a way to add a trusted user-agent value for the suitelet ?
I believe you will need to send your own header to fool NetSuite. Might you be having a different type of error? Have you tried using PostMan to see if you can indeed connect?
Well, I do not have the option to fiddle with the header in this case. So I found a work around. Got the request posted to an intermediate endpoint, modify the headers and then post it to NetSuite. I am using Google Could function in this case.
I’m facing the same issue with setting up a public suitelet, and came across this post. I see in the comments that a workaround using SSP applications works for you. I have written a small test .ss script, but when I create a new SSP application, the Touch Point is required. What touch point did you use to workaround sending your own User-Agent string to a public Suitelet?
Hi Wes,
I don’t believe you need a touch point. But you do need to be working with a site that leverages SSP. See my article: https://blog.prolecto.com/2015/04/18/learn-suitecommerce-advance-suitescript-server-pages-ssp-fundamentals/
Marty
Thanks Marty,
We currently use SiteBuilder with Elbrus Extensions for SiteBuilder
When I create a new SSP application record, touch point is REQUIRED.
Are you saying that I don’t actually need an SSP application record, and can just save the ssp scripts in the file cabinet in the SSP Applications folder?
Thanks,
Wes
Wes,
Based on my experimentation, you don’t need a touch point. See this reference article which is on topic: https://blog.prolecto.com/2015/04/18/learn-suitecommerce-advance-suitescript-server-pages-ssp-fundamentals/
Here, I created an SSP, no touch points, and put ss and ssp in the root and all worked.
Wow. OK Thanks, that worked.
Not sure what happened the first time I tried that.
It’s 2023 and this content is still relevant. Just had to use the “Mozilla/5.0” hack with Postman. Also, anecdotally I can verify that leaving the User-Agent out completely works.
Thanks Chris for the update. Keeping it all relevant!
Marty
When I use java to request the suitelet interface, from time to time a certain interface does not return a response for a period of time. At this time, other interfaces are normal, and postman can also access this interface. This problem started suddenly a few months ago and will be especially frequent on certain days.
Hi Kyara,
I wish we had more insight than you do on these kinds of concerns. It may make sense to create a monitor to watch the endpoint and then take the results to NetSuite Support.
Good luck.
Marty