netsuite — the one maintained client the ecosystem uses — and drives the container through the sequence an ERP integration actually runs.
Slug: netsuite
The account is in the realm and the host
One container serves one account, and the account id appears in two spellings of the same value: uppercased with an underscore in the OAuthrealm (1234567_SB1), lowercased and hyphenated in the host (1234567-sb1.suitetalk.api.netsuite.com). A request naming another account is an authentication failure, never a 404 and never an empty collection.
What it models
Advancing the sandbox runs the arithmetic of the books again: an invoice against the payments applied to it. A customer’s balance and overdue balance are derived on the way out rather than stored, so they move with the invoices and the clock without anything being written.
Scenarios
overdue-receivables, concurrency-exhausted, restricted-role.
Not modelled
The OAuth 1.0a and 2.0 authorization dances — the twin is handed live credentials. SuiteTalk SOAP, RESTlets, SuiteScript, workflows and approval routing, inventory and fulfilment, custom records and fields, saved searches, and OneWorld consolidation beyond the one seeded subsidiary. Taxes:taxTotal is always zero. Deleting a payment, and editing one, because both would move a receivable that has already been read.
Nobody who built this twin had a NetSuite account, so a handful of envelopes and codes had to be chosen from Oracle’s documentation rather than read off a live one — the strings inside INSUFFICIENT_PERMISSION and SSS_REQUEST_LIMIT_EXCEEDED, the unknown-id refusal, the idempotency window, and the unexpanded shape of a sublist. The twin’s own README lists them under Where the docs do not reach.