Skip to content
E-commerceFind, track and return orders.BankingSpending, cards and transfers.TravelConnections and rebooking.TelecomBills and roaming passes.InsuranceClaims from one sentence.
AnswersTheir own data, shown as your app’s cards instead of a paragraph.ActionsTasks done through your API, confirmed with a tap or undone with one.VoiceThey say what they need and the app does it.MemoryRemembers what each person prefers and uses it the next time they ask.Your brandLooks like your app on iOS, Android and the web.Setup by your agentYour coding agent adds it and fills in the console.EngageMessages people asked for, written for you and sent with one tap.AnalyticsWhat people did, what they asked, and what got solved.Human supportYour team answers inside the app, with the conversation in hand.ImproveAnswers ready for what it missed, and requests counted by who asked.Why RendelA chatbot talks about your app.How it worksThe six steps of a turn.SecurityWhat nothing happens without.CompareNext to the alternatives.
DocsEverything, in eighty pages.FlutterThe package, on iOS and Android.WebOne script tag.React NativeSoonPlanned.SwiftSoonPlanned.KotlinSoonPlanned.
BlogWhat we are working out.GlossaryThe words, one sentence each.
Actions

Your customers ask. Your app gets it done.

Rendel is the AI assistant inside your mobile app and website that does what customers ask through your own API: it starts the return, books the fitting, puts the shoe in the bag. Changes run as the customer, and nothing that can't be taken back happens until they tap Confirm.

Try the consoleBook a Demo

Halden’s console, an invented store with Rendel running. Yours for two hours, no sign-up.

Changed on the card, done with one tap

Halden's shopper picks another size before she confirms.

The problem

Your app can already do it. Customers still write to support.

Returns, bookings and coupons each have a screen your team built and tested. People who can't find it ask a help widget that answers with a link, or open a ticket someone answers by hand.

“How do I start a return?”

The return screen is there, three taps from the order. The question still lands with your support team, and each answer takes a person's time.

A help widget that only points

A chatbot beside your app can say where the button is. The customer still has to find it and do the task, and some give up on the way.

“Can't we just build an agent?”

Then engineering owns the hard parts: acting as each signed-in customer, a confirmation step, checking every value, retries that never send a change twice, and a record for audits. That is a project before launch and a system to run after it.

In a Gartner survey of 5,728 customers, published in August 2024, only 14% of service issues were fully resolved in self-service, and only 36% of the issues they called very simple. Gartner press release, 19 August 2024

How it works

Your app's own calls, ready to be asked for.

Rendel uses what your app already does. Your team decides how careful each action is, and the customer decides each change.

  1. Your actions come from your code and your API docs

    Your coding agent lists the calls your app already makes, and the console reads an OpenAPI page, a PDF or a Postman file for the rest. You switch on the ones you trust.

  2. You set how careful each one is

    Reads run at once and changes show a card first. A change that is easy to take back can run at once with an Undo, and one that deletes or can't be undone always asks.

  3. The customer sees your sentence, with their values

    Rendel's server writes the card from the sentence you gave the action and the values it checked, so the model can't reword what the customer approves.

  4. It runs as them, and goes on the record

    After the tap, the change goes through your API with the customer's own sign-in. Your team sees when, who, what and how it ended.

Watch one request go from a sentence to done

Doing the task

Done through your own API, as the customer.

Rendel can only use what your app registers or your team connects. Every change runs with the customer's own session and your API's own rules.

Customers get it done by asking

Your actions are one list, from your app's code and from your server. Rendel uses an action only while it is on that list and switched on.

Calls only your app can make stay in your app

A Firebase call, a GraphQL client or the cart on the device: your app registers the action and its handler runs on the phone, with the app's own session. Rendel holds no credentials for it.

Connect an endpoint without a release

Paste an address, link an OpenAPI page, or upload a PDF or a Postman file. Reads are tried once before they are offered; changes are never called while you connect them and come unticked.

  • Files up to 20 MB

Changes only as the signed-in customer

An endpoint on your server may change something only with the customer's own token, so each person reaches only their own data. A shared key can read, and goes only to its own host, over https.

Open Halden's Actions page in the demo console

The confirmation card

Nothing that can't be taken back happens before their tap.

Before a change that asks first, the customer sees one card that says what will happen. Rendel's server builds it, records the tap, and runs the change once.

The card says what will happen, in your words

The sentence is the one you gave the action, filled with checked values, and the model can't word it. Every amount on the card is one your app returned; a line that isn't is dropped.

Their yes is recorded before anything runs

A tampered app can't fake a yes: Rendel's server writes down the tap, for that device and that person, before your handler runs or your endpoint is called. A result sent without that record counts as declined.

Sent once, and done even if they put the phone away

A confirmed change on your server is called once, however often the app retries, and a lost answer is reported as unknown instead of being sent again. On recent builds it is made at the tap itself.

  • Running at the tap: Mobile SDK 0.73.0+ · Web SDK 0.50.0+

One clear question at a time

A change that asks first is never bundled with another action, so the customer answers one question. It can share the answer with what it is about: here are your points, shall I apply the code?

A card nobody answered never runs later

A card can be answered for ten minutes; after that it says nothing was done. If they left, Rendel tells them by push or in the app that something is waiting for their approval.

  • Approval notices: on for every app

The gravest changes get a stricter card

Deleting or cancelling gets a card that says it can't be undone, with the button in the warning style. For the gravest, your app can ask the customer to type a value back, or to read a long text in full, before the button works.

  • Type to confirm and Read all: set in your app's code, Mobile SDK 0.50.0+ · Web SDK 0.27.0+

Confirm a card on Halden's Test page

Undo

Small changes happen at once, with an Undo.

Saving to a wishlist, adding to a cart, following: changes nobody wants to approve one by one. When an action names the action that takes it back, it runs straight away and the answer offers Undo for ten minutes.

Done in one step, taken back in one tap

The answer opens with one line saying what was done, with Undo beside it. Undo runs once however often it is tapped, and the conversation knows it was taken back.

  • Off until you pick its undo
  • Mobile SDK 0.69.0+ · Web SDK 0.46.0+

Your team picks which changes may skip the card

On each action's Safety tab, pick the action that undoes it, or keep the card. A destructive action always asks, and the console warns when an Undo would remove more than was added.

Cards and forms

The card and the form ask only for what is missing.

Customers fix a value on the card instead of starting over, and forms arrive with what they already said filled in.

Change a value on the card, not the whole request

Mark a value changeable and the customer picks another time, size or quantity right on the card. The server checks it like the first one and redraws the card, so it always shows what will run.

  • Off until you mark a value
  • Mobile SDK 0.46.4+ · Web SDK 0.23.5+

It never picks an option for them

Where the refund goes is the customer's choice: if they haven't said, the card leaves it empty and the button waits. What they already said is shown as said, not asked again.

  • Empty values on the card: Mobile SDK 0.67.1+ · Web SDK 0.45.1+

Forms arrive filled in, and keep up with the conversation

A return form opens with the reason they gave already chosen. When they change their mind halfway, the open form is redrawn in place and everything they entered themselves stays.

  • Up to 10 fields, 13 kinds
  • Changing as they talk: Mobile SDK 0.28.0+ · Web SDK 0.6.0+

Try it in the demo console: change the size on an add-to-bag card

See the filled-in return on Halden's phone

Opening the right screen

When the answer is a screen, it opens that screen.

Some answers end on a page your app already has: the order, the bag. Rendel opens it through your own navigation, and only with values your app returned.

Opens your screen, through your own navigation

The answer offers the order or the bag as a card; a tap opens it with your app's own router, and a small bubble brings the answer back. An order number the model made up never opens a screen.

  • Up to 50 screens
  • Mobile SDK 0.38.0+ · Web SDK 0.15.0+

Answers about the screen they are on

Each question carries the screen it was asked from and the few before it, so “does this run small?” is about the shoe in front of them.

  • Web reads it by itself; mobile needs one line
  • Mobile SDK 0.62.0+ · Web SDK 0.41.0+

See what gets opened, and switch a screen off at once

The Screens page counts opens and offers over 30 days. Turn a screen off and Rendel stops offering it on every build, with no release, while people can still open it themselves.

  • Counts: Mobile SDK 0.46.5+ · Web SDK 0.23.6+

Open Halden's Screens page in the demo console

What it will never do

Inside the lines you draw, even when something fails.

The console can make any action stricter or switch it off at once. The server checks every call and every answer before anything reaches your app or your customer.

Stricter at once, never looser

Treat an action as destructive, or switch it off, and it applies on test and live straight away, with your reason in the audit log. Making it looser than your code declared takes a new build.

Checked on the server, every time

Every proposed call is checked against its action before a card is drawn or your app sees it. Forms that ask for a password, a one-time code or a card number are held back, and calls go only to public https addresses.

No changes for someone you made read-only

Label a person Read only and the assistant still answers them but offers nothing that changes anything; a card already on their screen can't be confirmed. Block stops answering them.

  • Owners and admins
  • For 1, 7 or 30 days, or until lifted

When something fails, they hear it plainly

A timeout or an error becomes an honest sentence, and your app keeps running. A failed lookup is never “nothing found”, and a change that didn't go through says so first.

Open Halden's Actions page in the demo console

Label a shopper in the demo console

Your team's view

Every action on the record, and in your hands.

See what customers had Rendel do, find the actions that fail, and try a change as a real customer before your customers do.

See who did what, and how it ended

When, who, on which device, with what values, who confirmed it and how it ended. Owners and admins export it as CSV or JSON.

Find the action that fails, and see why

Spot a failing action in two clicks: filter the list to Failing, Changes data, Off or Needs a key, then open it. Its page shows its calls in 7 days, how many failed, its median time, recent runs and every rule change.

Try it as a real customer first

On the Test page, Talk as signs in to your API as a test user, so your team sees the real card and the real call before customers do.

Your screens catch up with the change

When Rendel changes something, or the customer undoes it, your app hears about it, so the bag on screen reloads instead of showing the old count.

  • One listener in your app
  • Mobile SDK 0.71.0+ · Web SDK 0.48.0+

Open Halden's Actions page in the demo console

In the demo console: Conversations › Action record

A walk through Halden

One return at Halden, from her sentence to the record.

Halden is an invented shoe store with Rendel running for five weeks. This is the return its shopper Mira makes, as the demo plays it.

Mira returns a hoodie that's too small

Six steps, one read, one form, one card.

  1. 1She asks in her own words.1 / 6
  2. 2Rendel reads her orders through Halden's own action. A read runs at once. list_orders2 / 6
  3. 3The form arrives with the reason she gave already chosen. She checks it and taps Continue.3 / 6
  4. 4Rendel's server builds the card from Halden's own sentence. Nothing has changed yet.4 / 6
  5. 5Her tap is recorded first; then the return runs in Halden's app and the answer shows what happened.5 / 6
  6. 6One tap opens her order in Halden's app. Halden's team finds the return on the Action record: who, when, with what, and who confirmed it.6 / 6

Try it in the demo console

Open Halden's console, go to Test and ask to return the hoodie in your own words, then change the size on an add-to-bag card. Both land on the Action record, under Conversations.

Try the console

Or see the shopper's side on Halden's phone

Next to a separate tool

What changes when the task is done inside your app.

A support agent beside your app, an app inside ChatGPT or a framework you build on can all call an API. Here is where they differ from Rendel, row by row.

TopicRendel, inside your appA separate tool
Where the task finishesOn your app's own screens and cards, where the customer already isIn a chat channel, a widget or another company's app; the customer goes back to yours to see it
Whose permission it runs withThe customer's own session in your app, or their own token on your server; a shared key can only readUsually credentials set up for the tool, unless you build per-customer sign-in yourself
Before something changesA card Rendel's server builds from your sentence, with the tap recorded on the server; or an Undo for what is easy to take backAn approval step you design, or the host's own rules, which some let the user switch off
Made-up valuesChecked against each action before anything runs; amounts and screen ids must come from your own resultsWhatever checks you write
Switching one action offOne switch in the console, on every build, with no releaseOften a redeploy, or a setting in another product
When something failsA plain sentence; a lost answer to a change is reported as unknown, never sent twiceError handling you build and keep
Reaching people outside your appNot what it does: Rendel works inside your mobile app and websiteStronger here: chat channels, phone and email, or an assistant people open outside your app
What people asked for and couldn't doCounted for you in Requests to build, grouped across wordings and languagesFound by reading transcripts, if the tool keeps them

If you need one agent across chat, phone and email, a support platform fits better. If you want to own every part, a framework does. Rendel is for the tasks your app already does, done where your customers already are.

Comparing named products? See the comparisons

Controls and privacy

Your team decides what it may do. The customer decides each change.

Every console rule applies at once, every change waits for the customer's tap or comes with an Undo, and every run is on the record.

OWASP's 2025 Top 10 for LLM applications names “excessive agency” as a risk and lists ways to limit it. Here is where three of them sit in Rendel.

A person approves high-impact actions

Changes that can't be taken back wait for a tap on a card Rendel's server builds, and the tap is recorded before anything runs. Easy-to-reverse ones run with an Undo, and destructive ones get the stricter card.

Actions run as the specific user

Actions in your app use its own session. Changes on your server need the signed-in customer's own token.

Permissions are enforced downstream

Your API's rules decide what each person may do, and the server checks every value before it reaches your API.

OWASP, LLM06:2025 Excessive Agency

Who on your team can do what

What they can doOwnerAdminDeveloperAnalystConversation reviewerCustomer support
See the Actions and Screens pagesYesYesYesRead onlyYesNo
Connect, edit, switch on or off; keys; safety rules; Undo; screen switchesYesYesYesNoNoNo
Record confirmations on the server (the switch)YesNoNoNoNoNo
Read the Action recordYesYesYesNoYesNo
Export the Action recordYesYesNoNoNoNo
Test page, including Talk asYesYesYesNoYesNo
Label a person Read only or BlockYesYesNoNoNoNo

Every rule change is recorded in the audit log under the name of the person who made it.

What is kept, and what never is

  • The customer's token is used for the one call it was handed for, then dropped: never stored, logged, shown in the console or given to the model.

  • Emails, phone numbers and card numbers that users type are masked before the model sees them. The card the customer reads and the value your action receives are the real ones.

  • Conversations and action runs are stored in Frankfurt (AWS eu-central-1). The model's traffic is not used for training.

  • Each run is kept with its conversation for your app's retention window, 365 days unless you change it, and erased with the person when you erase one user.

  • Shared keys are stored encrypted, sent only to their own host over https, and never shown again.

  • Owners and admins can also mask names and addresses in what your actions return, and refuse attachments, with strict masking.

  • The customer can always say no: Go back, let the card run out, or tap Undo within ten minutes.

Read the security summaryActions in the security reference

Turning it on

It works with your app's own sign-in.

Your coding agent does most of it from one prompt. What it needs from your app is who is signed in and the calls you already make.

  1. Add the Mobile or Web SDK

    Any version reads and runs actions. The newer parts below draw only on builds that have them, and an older build keeps the card.

  2. Tell Rendel who is signed in

    Call identify after sign-in and reset on sign-out, and hand the SDK the customer's token before each question. Without it, changes on your server are not offered.

  3. Connect the actions

    Your endpoints become actions on the server; register in your app's code only what a server can't call. An endpoint that needs a shared key waits, switched off, until you add the key.

  4. Add what you want on top

    Undo pairs, values changeable on the card, screens with registerRoute, the listener that refreshes your screens, and push so approval notices reach the lock screen.

  5. Try it before customers do

    On the Test page, Talk as a test user and ask for the action. You see the real card and the real call.

On every plan, Pilot included. An action belongs to the answer it is part of: the question and the follow-up that carries its result count as one message.

Which build draws what

PartMobile SDKWeb SDK
Actions, confirmation cards, formsAnyAny
Changes on your server, as the signed-in customer0.27.00.5.0
Forms that change as they talk0.28.00.6.0
Opening your screens0.38.00.15.0
Values changeable on the card0.46.40.23.5
Screen opens counted0.46.50.23.6
Type to confirm, Read all0.50.00.27.0
The screen they asked from0.62.00.41.0
Card words in the conversation's language (EN, TR, DE, FR, ES, AR)0.67.00.45.0
Empty values the card asks for0.67.10.45.1
Undo instead of a card0.69.00.46.0
Your screens refresh after a change0.71.00.48.0
Done at the tap; a dot on the button while a card waits0.73.00.50.0

In the docs

What teams ask before they start.

  • Reads run at once. A change shows a card first and runs only after the customer taps Confirm; an unanswered card expires after ten minutes. If your team gives a change its undo, like saving to a wishlist, it runs at once and the answer offers Undo for ten minutes. A destructive action always asks.

  • For any change, the customer's own. An action in your app's code runs on the device with your app's session, and Rendel holds no credentials for it. An endpoint on your server may change something only with the signed-in customer's token, used for that call and never stored. A shared key can only read, and some reads need no key at all.

  • Every proposed call is checked against its action before a card is drawn: types, allowed values, bounds and required fields. Every amount on a card must be one your app returned, and an order number that opens a screen must come from your own results. The check proves where a value came from, not that it is right.

  • Yes, for values you mark changeable, like a size, a time or a quantity. The server checks the new value with the same rules and redraws the card, so it always shows what will run. Ids and amounts your app works out should never be changeable. It needs Mobile SDK 0.46.4 or Web SDK 0.23.5.

  • The customer gets a plain sentence and your app keeps running. A failed lookup is never reported as nothing found. A change that didn't go through says so first, and Rendel asks before trying again. If the answer to a confirmed change on your server is lost, Rendel says it can't tell whether it happened, instead of sending it twice.

  • No. Your coding agent lists the calls your app already makes, and the console reads an OpenAPI or Swagger page, a PDF reference or a Postman collection, so your team ticks the endpoints it wants. Only calls a server can't make, like an SDK on the device, are registered in your app's code.

  • Yes. Switch it off in the console and Rendel stops offering it on every build at once. You can also make it stricter, for example treat it as destructive, with your reason kept in the audit log. Making it looser than your code declared takes a new build.

  • Call anything your app didn't register or your team didn't connect, or open a screen you didn't register. It holds back a form that asks for a password, a one-time code, a card number, a CVV, a PIN, an IBAN or an ID number; the check reads field names, labels and placeholders, so a field called just “code” is not caught. It never calls private or internal addresses, and never follows a redirect.

  • Rendel's server records the tap itself before anything runs, and a result sent without that record counts as declined. A change on your server runs only for the person the card was drawn for. A confirmation proves a tap happened on that device, not who held it; turn on identity verification if that matters to you.

  • Yes. The Action record shows when, who, on which device, with what values, who confirmed it and how it ended. It is kept with its conversation for your app's retention window, 365 days unless you change it, and erased with the person when you erase one user. Owners and admins can export it.

  • Actions have no separate price, and every plan has them, Pilot included. You pay per message, one answer Rendel writes. A question and the follow-up that carries its action's result count as one message, plus one more for each started $0.02 of model cost.

  • Apps built with Flutter, on iOS and Android, through the Mobile SDK, and websites through the Web SDK. Any version reads and runs actions. Newer parts, like Undo or running at the tap, draw only on builds that have them, and an older build simply keeps the card.

Related

Put it in your app this week.

Start free on your own, or tell us what your customers do most and we’ll show you that exact workflow, working, in a tailored demo.

  • PilotFree400 messages a month
  • Starter$199 / month4,000 messages a month
  • Growth$799 / month20,000 messages a month
Start with the PilotBook a Demo
Every plan, and the estimatorOr try a live store’s console first, yours for two hours

Prefer email?

sales@rendel.ai

Prefer to write first?

Tell us about your app and we’ll show the right workflow in a tailored demo.

Help us tailor the demoOptional

We use this to get in touch about the demo and, if a partner introduced you, to credit them. We never sell it. See the privacy policy.