> For the complete documentation index, see [llms.txt](https://docs.taptap3d.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.taptap3d.com/proposed-reference/access-and-environments.md).

# Access and environments

Current local mock access and the proposed public-read, tenant and origin rules for future live integrations.

The product has not released a public API, hosted sandbox or API-key issuance flow. This page distinguishes what can be tested now from the proposed live connection.

## Environments

| Environment                     | Available?                           | Connection                                                  |
| ------------------------------- | ------------------------------------ | ----------------------------------------------------------- |
| Local contract mock             | Yes, in the documentation repository | `http://127.0.0.1:8787`; synthetic records, no credentials. |
| Hosted integration sandbox      | No                                   | No hostname or test account has been issued.                |
| Production public API and embed | No                                   | Example domains in these docs are placeholders.             |

The public documentation at `docs.taptap3d.com` is a docs site, not an API origin. Do not send listing requests to it.

## Proposed access model

Approved public listing reads require no bearer token. They are public content, so a publication ID must not be treated as a secret or used to share a private preview.

Private records remain under organisation membership checks. The public service resolves the owning organisation from the publication ID; clients cannot select a tenant using an organisation header or query parameter. Private creation, approval and administration routes are not specified here.

No proposed embed or public data request needs an administrative key. Keep existing storefront credentials in the server's secret store. Never place them in a URL, iframe attribute, browser bundle or support ticket.

## Registered origins

At live onboarding, register the storefront's exact origin: scheme, hostname and port. Staging and production are separate origins. Wildcard domains and a browser-supplied parent origin are not substitutes for a verified registration.

The intended iframe policy restricts which sites can frame a publication. Browser JSON rendering also requires CORS permission. Server-side JSON calls do not require CORS. Neither CORS nor frame permissions make public content confidential.

## Before a live connection

Binox must supply the actual origins, supported revision/locale behaviour, origin-registration process, request quotas, withdrawal propagation time and version-support policy. Those details remain release requirements rather than existing service commitments.

See [Connection playbook](/get-started/connection-playbook.md) for onboarding and [Release acceptance checks](/testing-and-support/acceptance.md) for validation.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.taptap3d.com/proposed-reference/access-and-environments.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `build a script that syncs our docs to a CMS` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.