Integration with NetSuite SuiteTalk Rest Web Services

(Continues with the Donut Case…)

“Flexibility” Platform is not only Internally, but open for Integration easily!

In the last Article — NetSuite/Deduce Scripts in Retail Practices, we built a custom record to store all Raw POS Transaction(s) inside NetSuite Platform. In this Chapter, let’s drill down the Integration Part about how to Setup the Rest Web Service API rapidly.

Very Simple, there are only 4 Steps without any Coding.

1. Create an Integration Record
2. Create a Specific Role for REST WebService
3. Create NetSuite Token Based Authentication (TBA /OAuth 1.0)
4. Testing the REST API with Integration Tool — Postman

Step 1 — Create an Integration Record

Token-Based Authentication (OAuth 1.0) to be used. Once the Integration is created, Keep the Consumer Key and Consumer Secret.

Setup > Integration > Manage Integrations

Step 2 — Create a Specific Role for REST WebService and assign to User

• Set up the Permissions Setup (i.e. REST Web Service / User Access Token)
• Set up the Permission custom Record (i.e. POS Record Table)
• Assign this Role to corresponding User

Setup > Users/Roles > Manage Roles (SubTab — Permission)

Step 3— Create NetSuite Token Based Authentication

• Token Id and Secret is generated in the Access Token Pages.

Setup > Users/Roles > Access Token

Step 4 — Testing the REST API with Integration Tool (i.e Postman)

Using REST web services, we can perform CRUD (create, read, update, delete) operations on NetSuite records without any code.

In this case, we will use Postman, which is API Tool for building and using and testing these APIs. You can download in here and using the Free Edition.

After adding the New Collection, we can set the Authorisation by using the Token generated in Step 1 and Step 3.

Authorisation Setting in Request Header (Inside Postman Collection)

• Signature Method to be set as HMAC-SHA256
• Realm to be set as <NetSuite Account Number>

OK! All basic setting and preparation are done. Let’s test the API:

GET Method (To Read the Single POS Record)

URL: https://<NetSuite Account Number>.suitetalk.api.netsuite.com/ services/rest/record/v1/<Record Name>/<Record Id>

https://tstdrvxxxxxx.suitetalk.api.netsuite.com/services/rest/record/v1/customrecord_sdr_main_product_table/708

**. customrecord_sdr_main_product_table is the script ID of the POS Custom Table

Once the API call successfully, the Status is 200 OK and return the JSON body as below:

Response from Get API call

POST Method (To Post a POS Record)

URL: https://<NetSuite Account Number>.suitetalk.api.netsuite.com/ services/rest/record/v1/<Record Name>

https://tstdrvxxxxxx.suitetalk.api.netsuite.com/services/rest/record/v1/customrecord_sdr_main_product_table

Post Method in POSTMAN to create a POS Record

Once the API call successfully, the Status is 204 OK (no Content)

New Record is created in the Custom Table

Patch Method (To update a POS Record)

URL: https://<NetSuite Account Number>.suitetalk.api.netsuite.com/ services/rest/record/v1/<Record Name>/<Record Id>

Patch Method in POSTMAN to update a POS Record

Conclusion

Comparing with old day (SuiteScript 1.0), we have to create the API by Restlet one by one.

SuiteScript 1.0

It is very convenient to working with the standard/Custom Record with standard REST web service API without coding. For example: calling the customer(https://tstdrvxxxxx.suitetalk.api.netsuite.com/services/rest/record/v1/customer/61).

What’s next?

However, for more advance integration, we still have to design our own Restlet API like the following idea:

1. Field validation and return Error Response
2. Data Response if the correspond field and report is updated
3. Try with OAuth 2.0 Authorisation Method

*** Design and Code by Wilson Cheng