## Finding Public Technical Documentation from the Docs Home Page
When you open a published Atloria documentation site, start with the public navigation that is visible on the docs home page. This is the safest place to begin because it shows only published content meant for readers. You are not looking at project-only editing screens here. Instead, you are using the same public-facing documentation experience that customers, partners, or support teams would see after documentation has been released.

From the docs home page, readers usually begin in one of three places:

- The main documentation navigation for standard help and setup pages
- A link or section labeled for API or technical documentation
- A technical category that groups generated reference material with related guides

If your question is broad, such as how a workflow works or which setup steps come first, begin with a standard documentation page. These pages are written in a more explanatory style and usually help you understand the task before you look at field-by-field details. If your question is specific, such as what a request needs or what a response returns, go to the API or technical reference area.

Published pages differ from internal project views because public readers only see released, shareable material. That means the navigation, headings, and links are focused on reading, not editing or managing documentation versions. You can move through categories, open published guides, and follow links into reference pages without seeing workspace-only controls.

This guide covers two reading modes inside published Atloria documentation:

- Browsing standard documentation pages for explanations and workflow guidance
- Opening generated API and technical reference pages for exact operation and schema details

[SCREENSHOT: Public docs home page showing main navigation, technical documentation section, and API/reference entry point]

## Moving Between Standard Docs Pages and Generated API Reference
A common reading pattern in published Atloria documentation is to start on a hand-written technical page and then open a generated reference page when you need exact details. This works well because the technical page gives you the purpose and workflow, while the generated page gives you the precise request and response information.

For example, you might open a technical guide first to understand an integration flow, setup order, or expected outcome. While reading, look for links that point to API reference or technical reference content. These links usually take you to a more structured page focused on a single operation or a related schema. The layout on these pages often feels more rigid and data-heavy because it is designed for exact lookup rather than narrative reading.

On generated reference pages, expect to see content such as:

- An operation name
- A request method and path
- Parameter lists
- Request body details
- Response structures
- Linked schemas or reusable definitions

By contrast, standard technical pages usually explain:

- When to use a feature or workflow
- Why one approach is preferred over another
- How multiple steps fit together
- Which related guides to read next

When you want to move back out of a detailed reference page, use the published navigation around the page. Breadcrumbs help you return to the parent section. Side navigation helps you jump to nearby topics in the same documentation area. In-page links often connect related guides and reference sections without forcing you to start over from the docs home page.

If you need a refresher on how reference pages are structured before reading them in public view, see [Understanding Entity Detail Pages in Technical Documentation](doc:understanding-entity-detail-pages-in-technical-documentation).

[SCREENSHOT: Published technical guide with a link into API reference and visible breadcrumbs for returning to the parent section]

## Reading API Documentation Effectively
When you open a published API reference page in Atloria, read it in a consistent order. This helps you avoid missing a required field or misunderstanding what the operation does. Start at the top of the page and work downward through the structured sections.

A practical reading order is:

1. Read the operation name to confirm you are on the exact action you need.
2. Check the request method and path so you know what kind of call the page describes.
3. Review any authentication notes before looking at the payload.
4. Inspect parameters and identify which ones are required.
5. Read the request body section if the operation accepts submitted data.
6. Finish with the response examples to see what comes back.

As you review fields, pay close attention to the labels and formatting cues on the page. Published reference pages typically distinguish required and optional values clearly. They may also show data types, allowed values, and nested structures.

Use this table as a reading checklist:

| What to inspect | What to look for |
|---|---|
| Required fields | Which values must be included for the request to work |
| Optional fields | Which values are available but not always needed |
| Data type | Whether a field expects text, numbers, true/false values, lists, or grouped objects |
| Allowed values | Whether a field accepts only specific choices |
| Nested objects | Whether a field contains sub-fields you also need to complete |

Example requests and example responses are especially useful when you are validating payload shape. If you are implementing a call, compare your planned request to the example. If you are troubleshooting a support issue, compare the returned data to the example response to see whether a field is missing, empty, or formatted differently than expected.

Also watch for cues that point to related material, such as linked schemas, shared models, or nearby operations. These links help you understand how one operation connects to others without leaving the published documentation area.

## Using Technical Pages to Understand Context Around the API
Published API reference is useful for exact details, but it does not always answer the bigger questions behind an integration or workflow. When you need context, leave the operation page and open a technical guide. In Atloria, technical pages are where you learn the order of work, the reason a step matters, and how related tasks connect.

Use a technical page when you need help with questions like these:

- Which step comes first in a workflow?
- What needs to be prepared before using an API call?
- When should one approach be used instead of another?
- How do several actions fit together in a complete process?

Technical pages usually provide information that generated reference pages do not. Instead of focusing only on fields and structures, they explain the surrounding task. You may find conceptual notes, setup guidance, sequence-based instructions, and links to related documentation areas. This is especially helpful when you are new to a topic and do not yet know which operation page to open.

Support-oriented readers also benefit from starting with technical pages. If someone asks why a process behaves a certain way, or when a particular action should be used, the answer is often easier to find in a guide than in a reference page. Once the context is clear, you can follow the guide’s links into the published API reference to confirm the exact request details.

This back-and-forth is normal in Atloria’s published documentation. A guide helps you understand the workflow. A reference page helps you confirm the exact operation. Cross-links between the two let you move from concept to implementation without losing your place.

If you want a broader introduction to reading reference-style material before switching between page types, see [Reading API and Technical Reference Pages](doc:reading-api-and-technical-reference-pages).

[SCREENSHOT: Technical documentation page with explanatory content and a linked API/reference section]

## Locating the Right Information for Support and Implementation Questions
When you are trying to answer a question quickly in published Atloria documentation, the fastest approach is to match the question type to the right page type. This saves time and helps you avoid reading a long guide when you only need one field name, or opening a reference page when you really need workflow context.

Use published API reference pages when the question is about exact details, such as:

- Which operation handles a specific action
- The name of a parameter
- Whether a field is required
- What a response field means
- How a schema is structured

Use standard technical documentation when the question is about process and decision-making, such as:

- The order of steps in a workflow
- What must be set up first
- Which integration path to choose
- How several calls or actions work together
- Why a task is performed a certain way

You can usually confirm which kind of page you are reading by checking the page heading, layout, and link patterns. Generated reference pages tend to have tightly structured sections, field tables, and example payloads. Authored guides usually have descriptive headings, narrative explanations, and links to related tasks.

When a support question spans both areas, do not start a new search right away. Instead:

1. Open the most relevant published guide or reference page you already found.
2. Use the page heading and section labels to confirm whether it is a guide or a reference page.
3. Follow embedded links on that page to move to the matching content type.
4. Use the linked page to validate the final answer.

This approach is especially useful when you need to answer a customer or teammate quickly. Following published links keeps you inside the correct documentation path and reduces the chance of landing on a similar but less relevant topic.

## Resolving Common Navigation and Reading Issues
Sometimes you land on the right published documentation area in Atloria but the page itself is not the right level of detail. The fix is usually simple once you recognize whether you are on a guide page or a generated reference page.

If you open a highly technical reference page and it feels too narrow or too detailed, move upward in the published structure. Use breadcrumbs near the top of the page to return to the parent section. If side navigation is available, use it to open the broader technical guide that sits above the operation page. This is the fastest way to regain context without leaving the documentation area.

If you have the opposite problem and a page explains the topic well but does not show the exact request fields you need, look for links labeled as API, reference, or related technical content. These links usually take you directly to the generated page with the operation details, parameter lists, and response examples.

When similar topics appear in more than one place, compare the page format before deciding which one to use:

- A conceptual guide usually has descriptive headings and explanatory text
- A generated reference page usually has structured field sections and example payloads
- A section landing page usually helps you choose between several related topics

If you need to share an answer with someone else, link to the most specific published page available. For field-level questions, share the exact operation or schema page. For workflow questions, share the guide that explains the process. This makes the answer easier to verify and reduces follow-up confusion.

For more on how published and project views compare when reading reference content, see [Using API Reference Pages in Published and Project Views](doc:using-api-reference-pages-in-published-and-project-views).

[SCREENSHOT: Published reference page with breadcrumbs, side navigation, and a related guide link highlighted]

## Overview
Published API and technical documentation in Atloria is designed for reading, not editing. As a public reader, you move through released documentation using visible navigation, page headings, breadcrumbs, side menus, and links between guides and reference pages. The main goal is to help you find the right level of detail for the question you are trying to answer.

There are two main page types to recognize:

- Standard technical pages, which explain workflows, setup order, and implementation context
- Generated API or technical reference pages, which show exact operation details, request fields, response structures, and related schemas

The most effective reading pattern is usually to begin with the page type that matches your question. If you need context, start with a guide. If you need exact field-level detail, start with a reference page. From there, use embedded links to move between the two. This is especially helpful for support work, implementation planning, and troubleshooting published documentation with other teams.

A few cues make navigation easier:

- Public navigation helps you browse only released content
- Breadcrumbs help you move back to a broader section
- Side navigation helps you compare nearby topics
- In-page links help you jump directly to related guides or reference details

If you already understand how individual detail pages are laid out, this guide helps you apply that reading approach in the public documentation experience. For the next step, continue with [Exploring API Reference Sections Inside Projects](doc:exploring-api-reference-sections-inside-projects) to see how similar reference material is accessed from within a project workspace.

## Prerequisites
Before using this guide, it helps to have a few basics in place so the page types and navigation patterns are easier to recognize.

You should already be comfortable with:

- Opening published documentation and browsing public-facing pages
- Recognizing the difference between a general guide and a detailed reference page
- Reading headings, navigation menus, and breadcrumbs to understand where you are in the docs

This guide assumes you have already read [Understanding Entity Detail Pages in Technical Documentation](doc:understanding-entity-detail-pages-in-technical-documentation). That earlier guide explains how detailed technical pages are organized, so this document focuses on how to read those pages once they are published and linked from public documentation.

It is also helpful if you can identify the kind of answer you are looking for before you begin:

- For workflow or setup questions, plan to start with a technical guide
- For field, request, response, or schema questions, plan to start with API reference
- For mixed questions, expect to move between both page types using embedded links

You do not need access to Atloria’s internal project workspace for this guide. Everything here is about the published reading experience: the pages, categories, and links available to public readers after documentation has been released.