Guide · NetSuite on InfiPlex
NetSuite integrations fail in a handful of known ways: the account's concurrency limit, the separate 60-second and 24-hour rate windows, a custom field or SKU that does not map, and, with Advanced Item Location Configuration on, location inventory that only SuiteQL still returns. InfiPlex already resumes a failed pull from its checkpoint, logs every attempt, and alerts on any log type through its NetSuite integration. An AI agent on the InfiPlex MCP server takes the part a person used to do each morning: which orders did not push, what the log says, what NetSuite field the order is missing, and whether the inventory pull is current.
Why NetSuite
The NetSuite failure and recovery guide lists what actually breaks: around 15 concurrent requests shared across SOAP, REST, and RESTlets, rate windows that throttle a steady poller, a custom body field that rejects a value, an item that NetSuite cannot find by SKU. InfiPlex writes every one of those outcomes to the shop log and resumes from the checkpoint. What was still manual is the morning review: open the log, find the failed pushes, open each order, work out which field is wrong. On an InfiPlex instance the agent does that as a conversation.
| What your team asks the agent | Tools it calls | What it hands back |
|---|---|---|
| "Which orders failed to push to NetSuite since midnight?" | log_types_get, then log_search on the NetSuite push failed type with a date window |
Order ids, the time of each attempt, and the reason text from the log message |
| "What NetSuite fields does 4419040 carry?" | order_search with search_term and include_order_additional_info 1, or order_get |
netsuite_class_id, netsuite_location_id, netsuite_ship_method_id, every netsuite_custom_field_* on the order |
| "Which open orders have no NetSuite class set?" | order_search not fully shipped with include_order_additional_info 1, filtered by the agent |
The list missing netsuite_class_id, so it can be set before the next push |
| "Set class 5 on 4419040" | order_additional_info_create with additional_info_name netsuite_class_id |
The field written on the order; the push logic consumes it on the next cycle |
| "When did the last NetSuite inventory pull land, and what did it set for GL-410?" | log_search on the NetSuite inventory pull types, inventory_change_history_get |
Last successful pull time and the change entries whose cause is the pull, with the resulting totals |
| "Is the Amazon channel pushing to NetSuite yet, or still on the old connector?" | shop_setting_search with search_term netsuite |
The per-channel NetSuite settings and their current values, read-only |
Every tool above is documented on the tools reference. The custom field mapping and order rules article lists every netsuite_* field the push consumes.
Failed pushes
InfiPlex checks NetSuite for the specific order before every push, then pushes, then logs the result. A push that NetSuite rejected sits in the log with NetSuite's own message: an invalid reference on a custom field, an item not found, a request limit. An operations lead on a read-only key at 8 AM:
Additional info, status, and notes are direct writes on a key with Write Orders, because none of them reaches NetSuite by itself; the push consumes the corrected field on its normal cycle. Nothing on this page pushes an order to NetSuite from the agent. That stays InfiPlex's job, with its check-then-double-check for the order already existing, described on the connector migration guide.
Field mapping
NetSuite push reads a set of additional info fields on the order: netsuite_class_id, netsuite_location_id, netsuite_department_id, netsuite_ship_method_id, netsuite_terms_id, netsuite_customer_id, netsuite_order_status, and a netsuite_custom_field_* wildcard whose suffix is the literal NetSuite field id. Order Automation fills most of them by rule; the agent covers the exceptions.
order_search text_search accepts additional info:netsuite_class_id=5, so "show me every open order going to class 5" is one call, not a report.
The agent reads the order's current fields first and confirms the exact field name from your instance; an unknown name is stored but maps to nothing, so it never guesses a suffix.
order_additional_info_create writes one name and value. Class, location, department, ship method, a custbody date: each is one direct call on a key with Write Orders.
order_create accepts an additional_info array, so a phone order can be entered with its netsuite_class_id and netsuite_location_id in place and push clean the first time.
The field mapping article covers the three layers under this: the additional info fields, the Order Automation transforms that set them, and the connection-level push and pull rules. Bundle and kit lines are pushed as the bundle SKU, one line, as described in SKU groups vs bundles vs SKU maps.
Inventory
InfiPlex pulls NetSuite inventory by modified date on a schedule, over SOAP or over REST with machine-to-machine auth, where the REST path queries through SuiteQL so location-level quantities survive Advanced Item Location Configuration. The agent cannot read NetSuite directly. What it can read is the InfiPlex side of every pull: the log entry for the run, and the change history entry the run wrote on each SKU.
If the gap had been on the InfiPlex side, the fix is an inventory write, which is previewed: inventory_set shows the current and new quantity and waits for confirmation, then propagates to every channel. On a NetSuite-as-master account the agent should recommend correcting NetSuite instead and letting the next pull carry it, which is what it is instructed to do when the change history shows the pull as the source of truth.
Keys by role
The MCP server publishes a tool only when the key carries its scope, so the key is the whole permission model. Create each at Tools > Admin API on your instance with MCP Enabled, and send the URL and header from the set-up guide.
Read Orders, Read Inventory, Read Warehouse, Read Log, Read Settings. Both MCP flags No. Every failed-push and inventory question on this page works; nothing can change. Credential settings, including the NetSuite token, return only whether a value is set.
Add Write Orders. Additional info fields, notes, and status write directly, so the agent can make an order push-ready. Inventory stays read-only unless Write Inventory is added, and then it is previewed.
Same scopes as the order desk key, used by an unattended agent from cron. The failed sync watch agent already reports every failed channel call each morning; point it at the NetSuite push and pull types and it writes the list with reasons before anyone logs in.
Prompts
The agent reads log type labels from your instance rather than guessing them, so "NetSuite push failures" resolves to whatever your instance calls that type. More prompts by role are on the prompts page.
Frequently asked
No. There is no push tool. InfiPlex pushes on its normal cycle, checking NetSuite for the order first so nothing is created twice. The agent makes the order push-ready by reading and setting its netsuite_* fields, and tells you which orders did not push and why.
Not through InfiPlex. It reads the InfiPlex record of every NetSuite exchange: the log entry for each push and pull, the change history entry each pull wrote, and the fields on each order. That is enough to say whether InfiPlex and NetSuite agree and, when they do not, which side moved last.
order_additional_info_create on an existing order, and the additional_info array on order_create. Both write the key-value fields the push consumes, including any netsuite_custom_field_* name. They execute on the first call because nothing leaves InfiPlex until the push runs.
Yes. InfiPlex writes NetSuite's response into the log message on a failed push or pull, and log_search returns it decoded. That is how the agent can distinguish a request limit, which InfiPlex retries, from a field or item problem, which needs a person or a mapping change.
Everything that writes. Write tools are not published to a key without write scopes, so an agent on a read-only key has no additional info, note, status, inventory, or setting tool to call. It can read orders, inventory, warehouses, settings, and the log, which covers every diagnostic question on this page.
No. The MCP server is included with API access on every InfiPlex plan. Keys are unlimited and MCP calls are not metered. Your AI vendor bills model usage.
Resources
We will connect an agent to a NetSuite instance on a read-only key and walk each failure back to its field, tool by tool.
Open Tools > Admin API, create a read-only key with MCP Enabled, and connect the assistant your team already uses. Questions: Contact us, email info@infiplex.com, or call 888‑770‑0857.
Order ids, SKUs, quantities, times, field values, and warehouse names are examples. NetSuite is a trademark of Oracle and/or its affiliates. Model Context Protocol is an open standard.
InfiPlex provides eCommerce companies, warehouses, and 3PLs with a robust platform to manage their sales channels.
©2026. All Rights Reserved. Privacy Policy | Terms & License