I started writing a full blog post on this but ran out of time. So here’s your executive summary.
Forget everything you know about how to locate your sandbox’s web service URL, once your sandbox gets “upgraded.” I still don’t know what “upgraded” means. All I know is my URL changed. NetSuite has documentation on this. But it’s close to impossible to find what I’m about to tell you here. And, if you don’t get this right, there’s a chance (this happened to me) that you’ll think you are connecting to your sandbox, but in fact, you are connecting to your production NetSuite. Yikes!!!!
Bind your web reference to:
https://XXXXXXX-sb1.suitetalk.api.netsuite.com/wsdl/v2017_2_0/netsuite.wsdl
where XXXXXXX is your account number.
There is lots of confusion in NetSuite docs regarding whether you need the 1 at the end or not. I found the 1 was absolutely necessary. And don’t miss the dash… “-sb1”.
Also, make note, if your SuiteTalk apps have been around for some time, or originated by emulating NetSuite’s examples (NSClientCRM or NSClientERP), then you are probably using the wrong entry point. Up until yesterday, my SuiteTalk apps had been using v2016_2_0. In my dealings with NetSuite support, I was made aware of v2017_2_0. If there is another entry point that newer, somebody let me know.
The other thing that very important to understand and hard to find in NetSuite’s docs, you MUST change your account that you use to login to your sandbox.
You must add an underscore, not a dash, followed by “SB1” to your account number. If you don’t, you run the risk of connecting to your production NetSuite.
In summary, 2 things need to change. Failing to get them right can result in thinking you are safely working in your sandbox, when in fact, you are working in production NetSuite.
Here is some extra reading for you overachievers!
NetSuite Experiences 