The chatbot that reads NetSuite
without an HTTP node in sight

Connecting NetSuite to a chatbot used to require a developer. You needed the REST endpoint URLs, the OAuth 1.0a signing logic, the exact NetSuite field names, and a workflow branch for every customer scenario you wanted to handle. One typo in a field name and the call failed silently with a 400 response and a cryptic message. One change in NetSuite's schema and your workflow broke.

Velaro's NetSuite AI Skills change the architecture entirely. The bot picks the right operation from a library of 46 pre-built actions based on what the customer types. The OAuth credentials are stored once, server-side, encrypted, and never touched again. The customer's email from prechat is the lookup key — no re-identification prompts. Every skill executes, validates, and returns.

What a skill actually is

A NetSuite AI Skill is a named, pre-built, pre-authenticated operation the bot can execute — netsuite_search_orders, netsuite_create_case, netsuite_check_stock. Each one wraps a specific NetSuite REST call: the correct endpoint URL for that record type, the OAuth1 signing logic, the field validation, and the error handling. The customer never touches any of that. Neither does the person who configured the bot.

The AI model reads the conversation and decides which skill to call. "Where's my shipment?" triggers netsuite_search_orders. "I want to return this" triggers netsuite_search_orders to find the order, then netsuite_create_rma to open the return. That two-step chain happened because of the conversation — not because someone built a workflow branch that said "if intent = return, then call order lookup, then call RMA creation."

The difference between a chatbot that feels like a search form and one that feels like an agent who pulled up the account.

Why HTTP nodes were a developer problem

HTTP workflow nodes gave you a blank canvas for calling any API. That canvas required you to know: the exact NetSuite REST URL for each record type (leads aren't at /lead — they're at /customer with a searchstage=Lead parameter), the OAuth 1.0a signature construction (nonce, timestamp, HMAC-SHA1), the exact field names for every write operation (wrong field = silent failure), and if/then branching logic for every scenario. When you needed six things, you built six nodes. When NetSuite changed a field name, all six broke.

Skills replace all of that. The field names are validated against NetSuite's live metadata API. The OAuth signing happens server-side against the stored credential config. The record type routing is internal. You never write an API spec. You never touch a payload.

What custom code and bundles still couldn't do

Before AI Skills, Velaro's NetSuite connection already did real work — HTTP wrappers handled OAuth signing, routed to the correct record types, and covered a substantial set of operations. That wasn't the problem. The problem was everything that happened above the API layer: you still had to author explicit workflow branches for each scenario, manually map the customer's prechat email into every lookup call, wire response fields back into conversation variables, and rebuild or re-test any time a requirement changed.

The bot also had no concept of who the customer was unless you explicitly threaded the identity through every node. A customer who entered their email in the prechat survey still got asked "what's your account email?" mid-conversation — because no prior approach treated that email as a first-class persistent session attribute available to every downstream call automatically.

Skills remove all of that authoring work. The AI reads the conversation, selects the right operation, passes the prechat identity as the implicit lookup key, and chains multiple steps when the conversation calls for it — without a single workflow branch written by anyone. The API layer is identical. What changed is everything above it.

What skills and MCP are not the same thing

MCP (Model Context Protocol) is the transport layer that connects the AI to tool implementations — the plumbing, not the tools. Velaro's NetSuite Skills are pre-built named operations that run over MCP. Saying "just use MCP" is like saying "just use HTTP" — it describes the protocol, not the application.

Building raw MCP for NetSuite yourself means: building and hosting a tool server, implementing OAuth1 signing, defining every operation as a tool schema, handling error states, validating field names, and deploying infrastructure. That's the same developer burden HTTP nodes created, now expressed in a different format. Velaro's Skills are the application layer above MCP — pre-built, pre-authenticated, and maintained by Velaro as NetSuite's API evolves.

The implicit identity advantage

Every other integration approach — HTTP nodes, bundles, raw MCP — requires you to explicitly pass the customer's identifier from the conversation into the API call. That means building the variable reference, mapping it into the request body, and testing that it actually flows through. Miss a step and the lookup has no key and returns nothing.

Velaro Skills thread the visitor's session identity automatically. The email, name, and phone collected in prechat are the implicit lookup key for every skill call. When the bot calls netsuite_search_orders, it already has the customer's email from the conversation — it doesn't ask "what's your account email?" The result is a chatbot that starts from who the person is, not from a blank form.

How to connect NetSuite with AI Skills

What the bot can do without any workflow authoring

Once connected, a bot with the NetSuite AI node handles all of these from a single conversation — no branching, no additional nodes, no workflow per scenario:

• Search for a customer by email, name, or phone and return their full profile
• Show open orders with status, line items, and shipping details
• Display open invoices and payment history
• Show current cases and their status
• Create a new support case directly from the conversation
• Check real-time inventory and flag low-stock items
• Return customer-specific pricing tiers for any item
• Create a return/RMA with line items and reason code
• Create a lead when a prospect chats (field-mapped from prechat data)
• Push the full conversation transcript to the customer's NetSuite record at close
• Call any custom SuiteScript via the Restlet skill

What a skill actually is — and why it's not a REST wrapper

A REST wrapper makes an API call easier to invoke. That's all it does. You still decide when to call it, you still pass the customer's identity in manually, you still author what happens before and after. The wrapper is one line of a program. You write the rest of the program.

A skill is different in three concrete ways:

1. The AI decides when to call it — not you. Each skill has a semantic description the language model reads. "Use netsuite_search_orders when the customer asks about an order, shipment, or delivery." The LLM reads the conversation and decides whether to call this skill, which skill to chain next, and when it's done. You never write that routing logic. It doesn't exist in a workflow file anywhere.

2. The customer's identity is already there. A REST wrapper receives exactly the parameters you pass it. A skill runs inside a conversation context — it can see the visitor's name, email, and phone that were captured when they opened the chat. It uses those as the lookup key without being told to. The customer typed their email once, in prechat. Every skill call that follows uses it automatically.

3. The credentials are inside the skill, not in your workflow. When a REST wrapper makes an API call, something has to hold and pass the OAuth credentials. That something is usually your workflow, your node configuration, or your environment variables — all places credentials can be read, logged, or accidentally exposed. A skill holds a reference to an encrypted credential config. At execution time, the skill retrieves the credentials, signs the request, and discards them. The credentials are never in the workflow. They are never in the prompt. They are never in the response.

The REST call at the end is identical either way — a signed HTTP request to NetSuite's SuiteTalk REST API. What's different is everything that decided to make that call, who it's making it for, and how the credentials got there. Velaro has been a BFN-certified NetSuite partner since 2008 — the skills are built on knowing exactly how the API behaves and where it breaks.