Is an Auto-Travel / Auto-Anything ESO Addon Allowed? Forbidden and Impossible Are Two Different Questions

What this page was checked against

Built 2026-08-22. Checked against the live game as it stood that day: interface (API) version 101050, which is Update 50, live since 2026-06-08. The next interface bump, Update 51, goes live on PC/Mac on September 28, 2026. Every rule quoted below carries the date it was fetched — all of the ESOUI quotes on this page were fetched on 2026-08-22, and the Update 51 date was verified at the ZeniMax announcement on 2026-08-19 and not re-fetched since.

You can read your own client's number in-game. The ESOUI dependency sticky gives the command verbatim: "/script d(GetAPIVersion())" (esoui.com/forums/showthread.php?t=9149, fetched 2026-08-22). If that prints 101050 you are on the same build this page was written against.

Two questions, not one

FORBIDDEN is a policy question: does the game's operator prohibit it, and what happens if you do it? The answer lives in ZeniMax documents and enforcement, and the next step if the answer is yes is "don't".

IMPOSSIBLE is a capability question: can an addon do it at all, given what the game's interface exposes to addon code? The answer lives in the interface documentation and is measurable, and the next step if the answer is yes-it's-impossible is "stop looking, no addon does this".

They come apart in both directions. Something can be technically possible and against the rules. Something can be flatly impossible while the rules say nothing about it — in which case the ban warning you were given is noise, because there is nothing to ban. Most of what people worry about in ESO falls in the second category, as the measurements below show.

The policy side: ZeniMax's rule text was not published on 2026-08-22

This is the fact that reorganises the whole question, so here it is with its measurements. Fetched 2026-08-22: https://account.elderscrollsonline.com/en-us/add-on-terms returned HTTP 200 and 106,692 bytes, of which the extracted body text was 1,022 characters — site navigation plus one sentence. That sentence, verbatim and in full: "This page is under translation." No clause text, no headings, no noscript fallback, no embedded data payload.

It is not a locale accident. The bare URL 302s to the same en-us page and returned a byte-identical 106,692 bytes on the same date. The French locale returned the same shell (106,878 bytes) with the same placeholder: "Cette page est en cours de traduction."

It is not confined to the add-on page. https://account.elderscrollsonline.com/terms-of-service, fetched 2026-08-22, returned the same placeholder — 941 characters of extracted text, all navigation — and https://www.elderscrollsonline.com/en-us/terms-of-service 302s to an error page. ZeniMax's support knowledge base was also unreadable to a plain client that day: a search for "add-on" returned HTTP 200 and 10,357 bytes whose entire extracted body text was the page title, "Support | The Elder Scrolls Online" — a JavaScript shell behind a challenge widget, with zero article links in the markup.

So on 2026-08-22, no first-party ZeniMax text stating what an add-on may or may not do was retrievable from any of those URLs. That is a dated absence, not a claim that no such rule exists. If the page is populated after that date, this section is the part of the page to re-check.

The absence has an odd consequence worth seeing. Add-on manifests routinely point users at exactly that empty page. SkyShards' manifest header carries the line, verbatim: "; You can read the full terms at https://account.elderscrollsonline.com/add-on-terms". We counted how common that is: of the 3,131 downloads in our addon corpus that contain a readable manifest, 1,226 carry a pointer to that URL in their manifest text (measured 2026-08-22). Well over a thousand add-ons refer their users to a page that serves one sentence, and the sentence is not a rule.

The sentence everyone repeats, which no source contains

There is a one-line formulation of ESO's automation rule that circulates constantly in guides, forum replies and chatbot answers, always presented as ZeniMax's own words. We searched for it case-insensitively on 2026-08-22 across the ZeniMax pages above, the four ESOUI stickies fetched that day, and the entire local addon corpus including the full 101050 interface documentation. Zero hits, in any form.

We are deliberately not reprinting the sentence, because reprinting it — even to debunk it — is how a sourceless line acquires the appearance of a rule. If you are given a crisp one-liner attributed to ZeniMax, ask for the URL. On 2026-08-22 there was no URL to give.

What IS quotable is ESOUI moderator guidance — and it is not a ZeniMax ruleCommunity-reported

The operative rules people actually follow come from an ESOUI sticky, "Please read BEFORE requesting addon/update/feature/create/take over" (thread 9865, opened 08/10/21, last edited 03/20/25, fetched 2026-08-22). It is community-maintained by a site moderator. It is not ZeniMax text, it does not quote ZeniMax text, and it should never be relayed as "ZeniMax says". With that label attached, here is what it says, verbatim, under its own heading "What addons cannot do".

The load-bearing sentence, the one every ban warning descends from, verbatim: "Obviously: Any other "botting related" automations. This is against the TOS and will get your account(s) banned from the game for sure!" Note what that is: a community assertion about a Terms of Service whose text we could not retrieve on 2026-08-22. It may well be accurate. It is not a citation.

The sticky's own link to the definitive list is unreadable, which is worth knowing before you go looking. Its anchor text reads "Please read what addons must not do at all and strickly follow these rules!" and points at wiki.esoui.com, which returned HTTP 403 on 2026-08-22 with 58 characters of body text: "Just a moment... Enable JavaScript and cookies to continue". The forums served fine the same day with the same client, so this is specific to the wiki host.

• Movement and combat, verbatim: "Move, jump, crouch, swim, block, or call any other movement or fighting related controls/actions of the player -> in any way (mouse, keybind, gamepad, whatever, ...)"
• Skills and keybinds, verbatim: "Cast skills in any way / Press keybinds that got to do with movement, combat etc."
• Starting interactions, verbatim: "Automatically start interactions that you usually need to do via a keybind (companion, banks, scrying, scribing, ...). You must start the interaction manually first to let the server properly init the methods and API functions needed."
• Chat, verbatim: "Send messages to chat (which others can see) directly. They are only allowed to add text to the chat message box and you manually need to press the return key to send."
• Scope, verbatim: "Include any external files in the addons that are not lua, xml or dds (texture files)." — the same list also rules out changing character/world visuals, playing custom sounds or 3D content, and "Exchange data between websites or use web services in real time."

The capability side, measured: 173 private, 40 protected, 5,423 unmarked

This part is not anyone's opinion. The interface documentation for the live build (apidoc_101050.txt, 29,475 lines) annotates each function's access tier inline. Measured 2026-08-22: 173 functions are marked *private*, 40 are marked *protected*, and 5,423 function signatures carry no tier marker at all — 5,636 functions in total.

The private tier is, almost exactly, the automation surface. Representative entries with their line numbers in the dump: MoveForwardStart (13197), MoveBackwardStart (13201), StrafeLeftStart (13217), JumpAscendStart (13225), ToggleWalk (13207), ToggleAutoRun (13249), RollDodgeStart (13251), PrepareAttack (13255), PerformAttack (13257), StartBlock (13259), OnSlotDown (13101), OnWeaponSwap (14439), ActivateSynergy (14445), ToggleMount (14396), SendChatMessage (13195). Also private: IsKeyDown (12393), SendPlayerStuck (18095), Disconnect (21220) and the entire crown-store product family.

Line up that list against the moderator guidance above and they are the same list. Move, jump, block, cast, weapon-swap, mount, send chat — every one of them is a private function. That is the useful finding: for the things people most often ask about, forbidden and impossible give the same answer, and the capability answer is the one you can verify yourself in an afternoon.

The protected tier is the inventory and action-bar surface: UseItem (21262), RequestMoveItem (13651), PickupInventoryItem (13675), PlaceInInventory (13649), PlaceInEquipSlot (13653), PlaceInActionBar (13647), PlaceInTradeWindow (12723), PlaceInStoreWindow (13655), PickupAbilityById (13667), SelectSlotAbility (14244), ClearSlot (14242), BindKeyToAction (13738), and the rest of the 40.

An honest limit on all of that: the dump contains no prose defining what "private" and "protected" mean. We searched it for any explanation and found only signatures. The only machinery that names the model at all is a handful of VM helpers — CallSecureProtected, IsTrustedFunction, LoadUntrustedString, SecurePostHook, InsecureNext (lines 6-13). So anyone telling you the tiers are "documented by ZeniMax" is over-claiming: they are annotated, not explained. What we can say is that the markers exist, that they are consistent, and that they land exactly where the community rules land.

Auto-travel specifically: the one we will not resolve for youUnverified

Wayshrine travel is the case that does not fit the pattern, and pretending otherwise would be the easiest mistake on this page. The function exists and it carries no tier marker. Verbatim from the live documentation at line 15384: "* FastTravelToNode(*luaindex* _nodeIndex_)". No *private*, no *protected*, sitting alongside GetNumFastTravelNodes (15351), GetFastTravelNodeInfo (15354), GetRecallCost (15386) and GetRecallCooldown (15392). There is no function named TravelToWayshrine anywhere in the build.

What that proves is precisely one thing: the marker is absent. It does not prove the engine permits the call from addon code, and it says nothing whatever about whether using it is permitted. Both of those would need a test we did not run and a rule document we could not retrieve.

The policy question is also live in the community rather than settled. An ESOUI thread titled "Wayshrine Travelling - verifying TOS" was open on the forum index when we looked on 2026-08-22 — i.e. addon authors themselves were asking, and had not been given an answer.

So our answer to "is auto-travel allowed?" is: unestablished, in both senses, as of 2026-08-22. We are not going to tell you addons can auto-travel and we are not going to tell you it is blocked. What would settle it: a populated Add-On Terms page, or a ZeniMax statement on that thread.

Auto-respec, auto-loot, auto-buy: the protected tier and what it impliesCommunity-reported

Anything that consumes, moves, equips, buys or slots an item runs through the protected tier — UseItem, RequestMoveItem, PlaceInActionBar, SelectSlotAbility and the rest of the 40 listed above. Since the documentation does not define what "protected" restricts, we will not tell you exactly what the engine allows. What we can point at is how working addons and tooling treat it in practice: as callable in response to a direct player action, and not from a timer or a repeating event.

That is also the operating rule inside this site's own addon generator, which is a concrete, checkable instance rather than a claim about the game. Its validator flags an action function called from a repeating timer or event context and refuses the build; the same function called from a button click passes with a warning.

The moderator guidance points the same way for interactions specifically, verbatim: "You must start the interaction manually first to let the server properly init the methods and API functions needed." — which the sticky attributes to ZeniMax anti-botting design, though again without a citation.

What the Addon Creator on this site refuses, and why

Since this site ships a tool that writes add-ons, it is fair to ask where it draws the line and on what authority. Its page says, verbatim: "Every addon is checked by a static validator before you see it: the Lua must actually parse, every API call must be real (not invented), and anything that automates gameplay is refused — ESO bans botting. The validator can confirm the code is valid and uses real API; it can't run it, so each addon ships with steps to verify it in-game."

The refusal it returns is, verbatim: "That would require automating gameplay (botting) — ESO bans it and the sandboxed addon API can't do it. I can build a version that runs when YOU click a button (e.g. at a vendor) instead. Try rephrasing it that way."

Two halves of that message stand on very different footing, and we would rather say so than let our own tool copy pass unexamined. "The sandboxed addon API can't do it" is measured — it is the 173 private functions above. "ESO bans it" rests on the ESOUI sticky's assertion about a Terms of Service whose text we could not retrieve on 2026-08-22. The refusal is correct either way, because the capability half alone is sufficient. But the ban half is community text, and our own page states it more firmly than the evidence supports.

The nearest thing you can actually haveUnverified

Read "permitted" here in a narrow, specific sense, because the broad sense is not available: it means not blocked by a tier marker in the 101050 documentation and not named in the ESOUI moderator list. It is not a ZeniMax ruling. No ZeniMax ruling on any of this was retrievable on 2026-08-22.

The shape that fits inside both constraints is: the addon watches, decides and tells you; you press the key. The moderator guidance describes exactly that pattern for chat, verbatim: addons "are only allowed to add text to the chat message box and you manually need to press the return key to send". Generalise it and you get the whole permitted design space — reminders, alerts, timers, a highlighted target, a pre-filled field, a one-keypress helper bound to a key you press.

A recall reminder that fires when your recall cooldown ends is on the readable side of the line: GetRecallCooldown (line 15392) and GetRecallCost (15386) carry no tier marker and are read-only queries. Reading state and telling you about it is what the unmarked 5,423 functions are overwhelmingly for.

If you want one built, the generator on this site will write it, and it will refuse the version that presses the key for you. That refusal is the line, expressed as software.

Where to get a binding answer (and why we could not establish one)Unverified

We tried and we failed, so here is exactly what was tried and on what date, rather than a plausible route we have not checked. The Add-On Terms page, the Terms of Service page and the support knowledge base were all fetched on 2026-08-22 and all three returned no rule text or no article text; the measurements are in the policy section above. We did not identify any URL that returns a ZeniMax statement on add-on automation.

There is one piece of genuine ZeniMax text on add-ons that we could retrieve, republished by ESOUI in its console sticky (fetched 2026-08-22), and it is discouraging about the existence of a ruling process at all. Verbatim: "The ESO team cannot assist with add-on related issues that players run into. It is up to add-on developers to fix any issues with their add-ons. We do not moderate, review, approve, QA, or guarantee ESO add-ons in any way." The same block, verbatim: "please be aware that add-ons (PC and Console) for ESO are UI add-ons only."

Read plainly, that says there is no pre-clearance: nobody at ZeniMax reviews or approves an add-on before you use it. It does not say automation is permitted, and it does not say it is not. So the honest state of the question is that a binding route could not be established on 2026-08-22 — and if someone tells you otherwise, the thing to ask for is the URL.

What this guide cannot tell youUnverified

Whether any of this is against ZeniMax's rules. Their add-on rule text was not published as readable text on 2026-08-22 at any URL we fetched. Everything on the policy side of this page is either a dated absence or community text labelled as such.

Whether auto-travel is permitted, or even possible. FastTravelToNode carries no tier marker, which proves only that the marker is absent. The community's own thread on it was open and unanswered on 2026-08-22.

What "private" and "protected" actually restrict. The documentation annotates the tiers and never defines them. We did not test any function against a live client.

What ZeniMax enforces, as opposed to what it publishes. Enforcement is not observable from any document we hold, and a rule that is not published can still be enforced.

How to get a ruling. We could not establish a route. ZeniMax's own republished statement says they do not moderate, review, approve or QA add-ons.

Whether the 101050 tier markers still hold after Update 51 goes live on September 28, 2026. They are measured against the current live build, and interface versions change what exists.