## Understanding Where API Reference Appears
In Atloria, you can read **API reference** content in two places: inside a project workspace and on the published public documentation site. The reference content may describe the same endpoints and schemas in both places, but the surrounding layout changes depending on where you open it.

Inside a project, you reach API reference pages from the project’s **technical documentation** area. You typically use the **left navigation tree** to move through documentation sections and open a reference page from the same sidebar that also contains other technical pages. This view is useful when you are reviewing documentation as part of project work, comparing reference pages with nearby guides, or checking how API content fits into the rest of the project structure.

On the public documentation site, readers arrive through the published docs navigation instead of the private project workspace. The page is presented as public-facing documentation, so the focus is on reading and sharing rather than working inside the project. Public visitors see the documentation content itself, along with the site navigation, page headings, and anchor links that help them move around long reference pages.

In both places, the main reading pattern is similar:

- A **left navigation area** or docs navigation for moving between pages
- A **main content area** for the selected API reference page
- Clear **endpoint** or **schema headings**
- **In-page links** or heading anchors for jumping to sections on the same page
- Links to related reference content, such as connected schemas

If you already worked through [Browsing Entity Reference Pages and Related Details](doc:browsing-entity-reference-pages-and-related-details), think of this guide as the same reading process viewed across both private project docs and public published docs.

[SCREENSHOT: API reference page showing left navigation, main content area, and in-page heading anchors]

## Browsing API Reference Inside a Project
When you are inside a project in Atloria, open the project’s **technical documentation** area and use the **documentation navigation** on the left to find API reference pages. These entries appear as part of the project documentation structure, so you can move between regular technical pages and API-specific pages without leaving the project workspace.

API reference pages are usually easiest to read when you treat the left navigation as your map. Resource groups, endpoint pages, and schema pages may be listed in the same documentation tree, and longer sections may appear under collapsible groups. If a section is expanded, you can quickly scan nearby entries to understand how the reference is organized before opening a page.

Once a page is open, use the page structure instead of scrolling from top to bottom. Long API pages often include nested headings that break the content into practical sections, such as:

- **Request parameters**
- **Authentication**
- **Request body**
- **Responses**
- **Schemas** or related models
- **Examples**

These headings are especially useful when Atloria shows a **table of contents** or linked heading anchors. Click the section name to jump directly to the part you need, rather than reading the full page in order. This is helpful when you only need to confirm a field name, check whether a parameter is required, or compare response details.

Project view is also useful because nearby pages often connect reference content with explanatory docs. You may move from a task-focused page to an endpoint page, then follow a schema link to inspect field definitions more closely. Collapsible navigation groups, linked headings, and cross-links between technical guides and API reference pages make this much easier.

[SCREENSHOT: Project technical documentation view with API reference entries expanded in the left navigation]

## Reading Published API Reference as a Public Visitor
Published API reference in Atloria appears in the public documentation site layout. The content may mirror what exists inside the project, but the reading experience is designed for visitors who are browsing documentation rather than working in the private project workspace.

As a public reader, you usually arrive in one of three ways:

- By opening the published documentation home or section navigation
- By selecting an API reference page from the public docs menu
- By following a direct link to a specific reference page or anchored section

The public view keeps the focus on reading. You use the visible documentation navigation, page headings, and anchor links to move through the content. If the public site includes browse or search controls, those can help you find a specific endpoint or schema page faster, especially in larger documentation sets.

The biggest differences from project view are the surrounding context and presentation. In public view, you may notice:

- Public-facing **branding**
- A cleaner reader layout with no project workspace context
- A **public page address** you can share directly
- The absence of project-only surroundings and internal working context

Even with those differences, the page content is still read the same way. Look for the endpoint title, grouped sections, and linked schemas. If you need to send someone to an exact part of the page, use the page’s heading anchor. When a heading has a linkable anchor, you can copy or share that anchored page address so the reader lands on the exact endpoint or schema section instead of the top of the page.

This makes public API reference especially useful for external reviewers, customers, or partners who need direct access to a specific operation or schema definition without opening the full project workspace.

[SCREENSHOT: Public documentation page showing API reference content with public navigation and anchored section links]

## Using the Information Shown on an API Reference Page
An API reference page in Atloria is easiest to understand when you read it from the top down once, then return to the sections you need. Start with the main identifier for the operation or schema. On an endpoint page, this usually includes the **endpoint title**, the **HTTP method** label, the **path**, and a short description of what the operation does.

Below that summary, the page usually breaks into grouped sections. For request details, pay attention to the labels that show where each value belongs:

- **Path parameters** for values included in the URL path
- **Query parameters** for optional or filtering values added to the request
- **Headers** for required request headers
- **Request body** for structured data sent with the request

When Atloria shows field lists or schema tables, look for indicators that separate **required** fields from **optional** ones. This helps you understand which values must be included and which ones can be left out. If a field name is unclear, follow any linked schema or related model reference to inspect its full definition.

Response sections are just as important. These often include:

- **Status codes**
- A **response body** structure
- Field descriptions
- Example responses

Use the status code area to understand what kinds of outcomes the endpoint can return. Then read the response schema to see what data comes back and how fields are grouped. Example payloads are especially useful when you want to compare the field list with a realistic response.

Some pages also show **authentication requirements** near the top or in a dedicated section. If authentication is listed, read that before reviewing request details so you understand whether the endpoint expects authorization information. Linked schemas and related reference pages help you connect one endpoint to the data structures it uses elsewhere in the documentation.

## Moving Between Conceptual Docs and Reference Content
In Atloria, conceptual guides and API reference pages work best together. A task-based guide explains **when** to use something and **why** it matters. An API reference page gives the exact details, such as parameter names, request structure, response fields, and status codes. When you are reading technical documentation, move between these two page types based on the kind of answer you need.

A common reading path starts on a guide page. You might be reading a workflow explanation, setup article, or integration walkthrough and then open a linked endpoint reference when you need exact request details. From there, you may follow links again to inspect a related schema and confirm what each field means. This is often the fastest way to move from general understanding to exact implementation details.

Typical navigation patterns include:

- Starting on a **task-oriented guide**
- Opening a linked **endpoint reference**
- Jumping to the **request body** or **responses** section
- Following a linked **schema** to inspect field definitions
- Returning to the guide after confirming the details

For documentation managers, this same flow is useful when reviewing published navigation. Check whether public readers can discover API reference pages through the docs hierarchy, visible links inside guide pages, and the published page structure. If a guide mentions an operation but the related reference page is hard to find, readers may miss important details.

Stay on a conceptual page when you need workflow context, explanations, or decision-making help. Switch to API reference when you need exact names and structures, including:

- Parameter names
- Header requirements
- Payload fields
- Response codes
- Schema definitions

For broader reading patterns across technical docs, see [Using API Reference Pages in Published and Project Views](doc:using-api-reference-pages-in-published-and-project-views) and [Exploring API Reference Sections Inside Projects](doc:exploring-api-reference-sections-inside-projects).

## Finding What You Need When a Reference Page Is Hard to Read
Some API reference pages in Atloria are long, especially when they include multiple request sections, large schemas, or detailed response examples. When a page feels hard to read, stop scrolling and use the page structure to narrow your focus.

Start with the **navigation tree** and the page’s **heading anchors**. If the page includes a table of contents or linked headings, use those links to jump directly to the section you need. This is usually faster than reading the full page in order. Focus on the section that matches your question:

- **Request** details when you need to know what to send
- **Authentication** when access requirements are unclear
- **Responses** when you need to know what comes back
- **Schemas** when a field definition is missing from the current section

If a link or layout looks unfamiliar, check whether you are in **project view** or **public view**. The same API reference content can appear in both places, but the surrounding navigation, branding, and page framing may look different. In project view, you are reading inside the project documentation workspace. In public view, you are reading the published documentation site.

When a field name appears without enough explanation, follow any linked schema or related endpoint. This is often where Atloria provides the missing context. A field may be briefly listed on one endpoint page but fully described on a linked schema page.

For collaboration, use the page address or a **heading anchor link** to share the exact section with someone else. This is especially helpful during reviews, because you can send a reviewer straight to the relevant endpoint, response block, or schema definition instead of asking them to find it manually.

[SCREENSHOT: Long API reference page with anchor links highlighted for request, responses, and schemas]

## Overview
Reading API reference in Atloria is mainly about understanding **where you are** and using the page structure well. The same reference content can appear in a private project workspace and in published public documentation, but the reading tools stay familiar: navigation, headings, anchor links, and links to related schemas.

The most important ideas to keep in mind are:

- **Project view** is for reading API reference inside a project’s technical documentation structure
- **Public view** is for reading the published version in a public-facing documentation site
- The **left navigation** helps you move between reference pages and nearby technical docs
- **Heading anchors** help you jump to request, response, authentication, and schema sections
- **Linked schemas** and related pages provide missing context when a field or structure is not fully explained on the current page

When you read an endpoint page, start with the top summary: method, path, and description. Then move to the section that answers your immediate question. If you need exact input details, go to request parameters or request body. If you need output details, go to responses and status codes. If a field is unclear, open the linked schema.

This guide focuses on reading and navigation across project and public contexts. If you need a deeper refresher on entity-style reference pages and related detail views, return to [Browsing Entity Reference Pages and Related Details](doc:browsing-entity-reference-pages-and-related-details). If you want to continue from here into how broader technical reference sections are organized, the next guide is [Browsing Technical Reference Sections and Entities](doc:browsing-technical-reference-sections-and-entities).

## Prerequisites
Before using this guide, you should already be comfortable moving around Atloria documentation pages and recognizing the difference between project documentation and published documentation. You do not need to create or edit reference content, but you should know how to open a project and browse documentation menus.

It helps if you already know how to:

- Open a project workspace in Atloria
- Browse the **technical documentation** navigation inside a project
- Open published documentation pages as a public reader
- Use page headings and sidebar navigation to move between docs pages

If those basics are still new, review these guides first:

- [Reading API and Technical Reference Pages](doc:reading-api-and-technical-reference-pages)
- [Managing Technical Documentation Browsing Inside Projects](doc:managing-technical-documentation-browsing-inside-projects)
- [Reading Published API and Technical Documentation](doc:reading-published-api-and-technical-documentation)

You will get the most value from this guide if you are trying to answer questions such as:

- Where do I find API reference inside a project?
- How does the same reference look in public docs?
- How do I jump to a specific request or response section?
- How do I share a direct link to one endpoint or schema section?

You do not need admin access for the reading tasks described here. The guide is written for readers, reviewers, and documentation team members who need to navigate API reference content efficiently in both private and public documentation views.