Actions

What are Actions?

An action is something your agent can do, not just say. When a user asks "where's my order?", a good agent shouldn't reply "let me connect you to support" — it should look the order up, check the status, and answer right there in the conversation. That's what actions are for.

An action gives the agent a tool. The agent decides, based on the conversation, whether a tool is relevant and what inputs to pass. If it calls one, the result comes back and the agent uses it to reply naturally to the user.

You don't write any code to wire this up. You describe the action in a short form, and Sudeem handles the rest — schema inference, parameter validation, execution, and rendering the result.

When to reach for an action

• Look things up — orders, products, tracking numbers, account info, availability.
• Write things back — create a ticket, update a status, log a lead, book a slot.
• Route to humans — post to Slack, page an on-call teammate, file a form.
• Render rich UI — show a product card, a list, a price breakdown, a booking form inside the chat.

If you find yourself writing a long system prompt that says "when the user asks X, tell them to email support" — that's a candidate for an action.

The four action types

1. Custom HTTP actions

The generic type. You give it an endpoint, an HTTP method, optional headers, and a set of parameters. The agent learns the action's name and description and calls it with arguments extracted from the conversation.

Use this for anything behind a REST API you already own: your internal admin API, a CRM webhook, a booking engine, a shipping tracker.

2. Salla integration actions

Pre-built actions for Salla stores. Connect your store once via OAuth, and the agent immediately gets typed tools for product search, order lookup, customer info, and more — no manual endpoint setup needed.

3. Shopify integration actions

Same idea for Shopify. One OAuth connect and your agent speaks fluent Shopify — products, orders, customers, fulfillment, discounts.

4. Slack integration actions

For escalations and team-facing flows. The agent can post messages, open threads, and page channels. Common use: when a conversation meets an escalation rule, notify the right channel with the full context so a human can step in.

Response templates

An API response is rarely what you want to show a user. 200 lines of JSON don't belong in a chat bubble.

Response templates let you map the raw API output to a readable reply — or even to a rich UI component. You write a small template that references fields from the response, and Sudeem renders the result inside the chat.

Two ways to use templates:

• Text reply — map fields into a short sentence the agent returns.
• Dynamic UI card — render a CustomTemplateCard component that shows a product, a list, a price breakdown, or a form inside the message stream.

The template is scoped to the action, so each action can have its own rendering without bloating the agent's prompt.

Note on large responses. Very large API responses are persisted in full but streamed to the widget through a hydration reference to stay under broadcast size limits. You don't have to do anything — Sudeem handles it automatically.

Approvals

Some actions shouldn't fire without a human say-so — refunds, cancellations, anything that writes to a payment system. Mark an action as requiring approval, and Sudeem pauses the turn, notifies your team, and resumes the agent the moment someone approves (or politely cancels the request if rejected).

While pending, the user sees "This action requires approval — we've sent it to the team" instead of silence. Your team gets an in-app notification with the full action context and the inputs the agent wanted to pass, so approvers see exactly what they're signing off on.

The playground

Every action page ships with a playground. Chat with the agent, watch which tool it picks for each message, and inspect the exact inputs it passed and the raw response it got back. It's the fastest way to build confidence that an action will fire when you expect it to — and not fire when it shouldn't.

Use it before every deploy. It catches schema mistakes, bad parameter names, and overly eager agents in seconds.

Designing actions well

A few rules of thumb we've learned the hard way:

• Name and describe the action for the agent, not the user. The agent reads the description to decide whether to use it. "Search real estate listings by city and price range" beats "Property API".
• Make parameter names obvious. city, max_price, property_type — not p1, cat, f.
• Keep responses focused. Return the 5 results the user cares about, not the full 500-item dump. Smaller responses = faster agent, cleaner UI, lower cost.
• Fail gracefully. If the API returns an error, return a short human-readable message in the response body. The agent will use it to apologize and suggest a next step, instead of freezing.
• Test in the playground first, every time. Don't ship an action you haven't chatted through.

Where to go next

• Intro → What is Sudeem and the five-minute quickstart
• Salla integration — connect your Salla store in two clicks (coming soon)
• Shopify integration — same, for Shopify (coming soon)
• Slack escalation — how to route conversations to your team (coming soon)