Your customers connect their NetSuite account once. Askel handles token provisioning and schema discovery, then maps transactions, custom record types, and saved searches to your product's data model without you writing a line of SuiteScript.
SalesOrders, Invoices, Customers, VendorBills, PurchaseOrders, and CreditMemos. Askel uses the SuiteTalk REST API and handles NetSuite's multi-subsidiary and multi-currency requirements automatically.
If your customer stores project milestones or equipment assets in a custom record type (customrecord_project_milestone), Askel discovers it, reads its field definitions, and lets you map it to your own schema.
Customers often encapsulate complex business logic in NetSuite saved searches. Askel can execute a saved search by its internal ID (e.g. customsearch_open_orders_by_rep) and page through its results on a schedule.
NetSuite custom fields have IDs like custbody_po_reference or custentity_tier. Askel surfaces these alongside their labels so your customer-success team can confirm the right mapping without reading SuiteScript.
Askel writes NetSuite's externalId field on every record it creates. That means repeat runs are idempotent: a duplicate run updates rather than duplicates.
If a customer's admin adds or removes a required field on a transaction type, Askel notices on the next run and pauses the affected workflow before bad data reaches NetSuite.
Verdant Fleet Management sells your field-service software. They run two subsidiaries in NetSuite, one per region, and use a custom record type (customrecord_service_contract) to track active contracts. Every time a contract is marked active in your product, their finance team expects a corresponding CustomRecord and a SalesOrder in the correct subsidiary.
Verdant's NetSuite admin navigates to Setup > Integration > Manage Integrations and creates a new Integration record. They enable Token-Based Authentication and note the client ID and client secret. They then create a role with the permissions your product needs (Transactions, Custom Records, Saved Searches) and assign it to a dedicated service user. That user generates a token ID and token secret for the integration.
Verdant's admin pastes the account ID, client ID, client secret, token ID, and token secret into the Askel setup screen inside your product. Askel mints a short-lived OAuth 2.0 M2M access token and confirms connectivity to https://verdant.suitetalk.api.netsuite.com.
Askel reads the metadata for Verdant's customrecord_service_contract type, the SalesOrder transaction type, and all custom fields (including custrecord_contract_sku and custbody_subsidiary_ref). Your CS team sees a mapping draft within minutes.
Two custom fields do not auto-map. Your CS rep reviews Askel's suggestions, confirms the correct fields with Verdant on a call, then runs a dry-run against 20 real contracts to verify the SalesOrder and CustomRecord payloads look correct.
The workflow is enabled. When a contract is activated in your product, Askel creates a customrecord_service_contract entry and a linked SalesOrder on the matching subsidiary in Verdant's NetSuite account, with externalId set to your contract ID for idempotent updates.
The customer's NetSuite admin creates an Integration record in their NetSuite account, generates client credentials, and pastes them into Askel. Askel mints short-lived access tokens per request via OAuth 2.0 M2M; no user passwords are stored. The connecting service user's role controls exactly which records and subsidiaries the integration can touch.
© 2025 Askel.ai. All rights reserved.