> ## Documentation Index
> Fetch the complete documentation index at: https://parabola.io/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Send to NetSuite — setup & internal IDs
> The key permissions difference for writing data, why internal IDs are required for every object reference, and three patterns for building reliable lookup flows.
Sending data back into NetSuite is where Parabola unlocks the most powerful automation patterns — automatically creating purchase orders, updating inventory records, or generating journal entries without anyone touching NetSuite manually. But there are a few important things to get right before your first flow works reliably.
***
## What's different from Pull
The Send to NetSuite step uses a **different API** than Pull from NetSuite:
* **Pull from NetSuite** uses NetSuite's SOAP API
* **Send to NetSuite** uses NetSuite's REST API
This means the role you set up in Lesson 2 needs one additional permission for Send to work: **REST Web Services** must be set to Full.
If you followed the setup in Lesson 2, you should already have this. If you only enabled SOAP Web Services, pull works but send will fail authentication.
***
## Permissions for Send to NetSuite
Beyond the REST Web Services permission, the key difference is in how you set access on individual record types.
For **Pull from NetSuite**, View access is sufficient — you only need to read data.
For **Send to NetSuite**, the relevant record types need **Full** access — Full means both read and write.
**Example permissions for creating purchase orders:**
| Permission | Level |
| ----------------- | ----- |
| REST Web Services | Full |
| Purchase Orders | Full |
| Items | View |
| Vendors | View |
| Locations | View |
Permissions in NetSuite are set at the **record type level** — you can't restrict access to specific fields within a record. If the role has Full access to Purchase Orders, it can read and write any field on a PO.
***
## Why internal IDs are required
When you send data into NetSuite, every reference to another object must be provided as that object's **internal ID** — not its name.
This applies to everything: vendors, items, customers, locations, subsidiaries, cost centers, currency codes — all of them. NetSuite doesn't do name-matching when receiving data via the API.
**Why this matters in practice:**
Even a small formatting difference — an extra space, a slightly different spelling, a name that's been updated — will cause a record creation to fail when using names. Internal IDs are stable numbers that don't change.
As a general rule: once you're building Send to NetSuite flows, use internal IDs everywhere. They have a much higher success rate than name-based matching.
***
## Finding internal IDs: two patterns
The most reliable approach: create saved searches in NetSuite for each object type you need to reference — Items, Customers, Vendors, Locations, Subsidiaries — and pull those into your Parabola flow before the Send step.
A complete Send to NetSuite flow typically looks like:
1. **Input data** (from spreadsheet, PDF, another system, etc.)
2. **Pull from NetSuite** — Vendor reference search (name + internal ID)
3. **Pull from NetSuite** — Item reference search (name + internal ID)
4. **Combine Tables** — join input data to reference searches to look up IDs
5. **Send to NetSuite** — create or update records using the mapped IDs
This pattern scales automatically — when you add a new vendor in NetSuite, your next flow run picks them up without any manual updates.
For teams where some members don't have NetSuite access, a Google Sheet can serve as the lookup table instead.
**Pattern:**
1. Create a Google Sheet with columns for the human-readable name and the corresponding internal ID (e.g., "Vendor Name" and "Vendor Internal ID")
2. Have the NetSuite admin populate it — or export a list from NetSuite and paste it in
3. Pull the sheet into Parabola using a Pull from Google Drive step
4. Join it with your input data using Combine Tables before the Send step
This works well for reference data that doesn't change frequently — like subsidiaries, cost centers, or a fixed list of standard locations.
***
## Subsidiary is almost always required
For most transaction types in NetSuite — journal entries, purchase orders, sales orders — subsidiary is a required field. If you try to create a record without specifying the subsidiary, it will fail.
Subsidiary must be provided as an **internal ID**, just like all other object references. Don't pass the subsidiary name — look up the ID first.
If all of your flows write to the same subsidiary, you can simplify this by setting a **custom/default value** directly in the Send to NetSuite step rather than looking it up dynamically each time.
***
## What's next
Now that you understand why internal IDs are required and how to look them up, the next lesson covers the supported action types, how to map fields correctly, and the most common gotchas that cause records to fail. In the building challenge there, you'll wire your vendor reference search directly into a Send to NetSuite step.
***
Build a reference search for the object type you'll need to look up internal IDs for. The steps below use Vendor as the example, but the same pattern applies to Items, Customers, Locations, Subsidiaries — whatever your Send flow will reference.
Go to **Reports > Saved Searches > All Saved Searches > New** and select the search type that matches the object you need to look up (e.g., **Vendor**, **Item**, **Customer**). Under Results, add two columns: **Name** and **Internal ID**. No criteria needed — you want the full list. Make it public and save.
Add a **Pull from NetSuite** step to your flow alongside the saved search from Lesson 3. Select the matching search type and find your new reference search. Confirm it returns two columns: names and internal IDs.
Add a sample data step (or pull in a small spreadsheet) with a name column representing what your source data would look like. Use a **Combine Tables** step to join this to your reference search on the name column. Confirm the output now includes an Internal ID column for each row.
**You're done when:** You have a Combine Tables step whose output includes an Internal ID column with numeric values for every row. That output feeds directly into the Send to NetSuite step in Lesson 6.