3DVista has no JavaScript API, and that is the whole problem

Their words, not mine

3DVista's knowledge base answers the JavaScript question directly, and the answer is: "Unfortunately we do not offer any guidelines or API regarding javascript." It points people at a users' group where some members have worked things out for themselves.

You can see the same fact from the other side. There are JavaScript API products for sale on 3DVista's own marketplace, written by third parties. Nobody sells you an API for software that already ships one.

What that actually means

It does not mean JavaScript is unsupported. The software will run your code and it will host your HTML. It means nothing about how your code meets the tour is a promise. No names are guaranteed, no shapes are guaranteed, and nothing is deprecated politely before it changes, because none of it was published in the first place.

So the risk in this work is not writing the code. It is that the code stops working on a Tuesday, in a client's tour, because of an update nobody told you about.

Rule one: depend on shape, never on a name

A name is the most fragile thing you can reach for. What survives is what an object can do, so ask that instead:

function hasTour(x){
  return !!(x && typeof x.getComponentByName === 'function'
              && typeof x.setComponentVisibility === 'function');
}

Now it does not matter what the object is called or where it came from. If it behaves like the tour, it is the tour. This one habit is the difference between a tool that breaks on a rename and one that does not notice.

Rule two: try, fall back, and never assume symmetry

Undocumented surfaces are lopsided. There is usually one clear way to change something and two or three unreliable ways to read it back, and which of them exists varies. So attempt them in order and keep your own record as the floor:

function getVisible(component, name){
  try { if (typeof component.isVisible  === 'function') return !!component.isVisible();  } catch(e){}
  try { if (typeof component.getVisible === 'function') return !!component.getVisible(); } catch(e){}
  return (name in myState) ? !!myState[name] : null;
}

Each attempt gets its own try/catch, because a method can exist and still throw on a component that is not mounted yet, and one uncaught throw takes your whole tool with it. And unknown returns null, not false. False means hidden. Null means you do not know, and code that confuses the two will do the wrong thing the first time it runs early.

Rule three: fail quietly, always

Your tool is a guest inside somebody's product. If it throws, the exception does not land in your code, it lands in the tour's event loop, and the visitor does not get a broken feature, they get a broken tour.

var tour = resolveTour(handedToMe);
if (!tour) return;            // no tour, no work, no noise
var c = tour.getComponentByName(name);
if (!c) return;               // renamed or deleted, still not a crash

Every single call into the tour returns early instead of throwing. A feature that silently does nothing is a support ticket. A tour that will not load is a refund.

Finding the surface without guessing

You do not have to reverse engineer anything clever. Publish a tour, open it, and look at what is actually there in the console. Read the object you are handed rather than theorising about it: list its methods, and write down the two or three you need.

Then, and this is the part people skip, write down the version you found it in. An undocumented dependency with no version noted next to it is a bug with a long fuse.

The morning it changes

It will, eventually. What decides how bad that morning is, is whether the vendor specific part of your tool lives in one place or is scattered through it.

Keep it to two functions: one that recognises the tour, one that resolves and caches it. Everything else in your tool talks to those. When an update moves the ground, you edit two functions and ship, instead of reading four thousand lines looking for every place you touched something you did not own.

That is the entire architecture. It is not clever. It is just the only shape that survives having no contract.

Why this is worth paying for

The software is excellent and most of what people want is already in it. Question cards, scoring, branching, reports: if that is your project, build it in the editor and keep your money.

This page is about the other case, where the thing you need is on the far side of a line the vendor has not documented. That work is real, it is maintainable if it is written properly, and it is a liability if it is not.

The companion piece is running your own HTML inside a tour, which is the same ground from the practical end. The work itself is 3DVista development.

What you get

• What 3DVista actually says about JavaScript, in its own words
• Why the third party API products on their marketplace exist at all
• The three rules for writing against something nobody has promised you
• How to find the surface yourself, without guessing
• What to do the morning an update changes it