HiScale SolutionsThe situation
A systems integrator buys most of its equipment from a distributor, and both companies run NetSuite. Every order was keyed twice, once as the integrator's purchase order and once as the distributor's sales order. Status came back by email, and minimum order quantities surfaced only when an order bounced. Other integrators that buy from the same distributor wanted the catalogue, their contract pricing and their invoices in their own systems instead of in spreadsheets. We built both ends.
What we built
The integrator's account. An approved purchase order shows a button that sends it to the distributor through a token-authenticated RESTlet call. A RESTlet in the integrator's account receives status updates from the distributor. It accepts a fixed list of fields and rejects anything else with a readable error. When goods arrive, a User Event on the item receipt reports the receipt back.
A Map/Reduce job pulls the distributor's catalogue into vendor item options, with minimum quantities and minimum order amounts. A User Event on the purchase order enforces those minimums line by line, and a buyer can tick a box to order below the minimum amount on purpose.
The distributor's account. An order RESTlet creates or updates a sales order from each incoming purchase order. An unknown item code becomes a placeholder line, errors are reported per line, and attached files come across with the order. User Events on the sales order and the item fulfilment send approval, fulfilment and tracking numbers back to the integrator's account through a signed RESTlet call. A failed call sends an alert from an email template.
For every other customer, a partner API serves the catalogue at that customer's own pricing, and their invoices. Catalogue lookups work by id or model, with a modified-since filter and paging from the last id seen. The invoice RESTlet returns up to 50 invoices per page, with extra fields on request.
What it does now
Orders move between the two accounts without re-keying, and the integrator sees the distributor's progress on its own purchase order. Each API customer receives an API key. A Suitelet exchanges that key for a NetSuite OAuth 2.0 machine-to-machine token by signing a JWT, so customers never handle NetSuite credentials. A button on the credentials record emails a customer its keys and creates the integration ids that limit every response to that customer's own data.
Under the hood
- The inbound status RESTlet checks every field against an allow list and maps status names to internal ids.
- Catalogue sync creates or updates vendor item options, so running it twice leaves the same result.
- Minimum quantity and amount rules run at save, with an explicit override.
- Keyset paging lets a customer walk the whole catalogue without offset limits.
- API access uses OAuth 2.0 client credentials with a signed JWT, scoped by the customer's integration id.
- A shared SuiteQL builder sits behind both API RESTlets, with JSDoc type contracts checked at build time.