## Opening a project and finding its documentation areas
In Atloria, start by opening the project you want to review from the main project workspace. Once you are inside the project, use the project navigation to find the documentation areas. Depending on how your team has organized the workspace, you will typically move between the main documentation area and the **API Reference** area from the same project navigation, rather than leaving the project and opening a separate public site.

The main documentation area is where you review written guides, setup instructions, how-to pages, and other narrative content. These pages usually read like end-user or team-facing documentation. The **API Reference** area is different: it is structured as reference content, where pages are grouped into endpoint sections, resource groups, or schema-based entries. This makes it easier to tell where explanatory guides end and where detailed request-and-response reference begins.

Inside a project workspace, these pages can be reviewed before they are publicly released. That means your team can open draft documentation, move through the page structure, and inspect API reference entries while the content is still internal. Look for signs that content is still in progress, such as draft labels, unpublished status indicators, or sections that appear only inside the workspace and not on the public documentation view.

This internal view is useful for several roles:

- **Writers** review page structure, wording, and navigation flow.
- **Managers** check whether the documentation is complete enough for release.
- **Administrators** confirm that the right people can access internal project content.

[SCREENSHOT: Project workspace showing the main navigation with documentation pages and API Reference visible in the same project]

## Browsing documentation pages inside the project workspace
When you are reviewing documentation inside a project, use the navigation tree to move through pages without leaving the workspace. The sidebar is the main tool for this. It lets you open top-level pages, expand grouped sections, and move into child pages in the order your readers will likely follow after publication.

Open a page from the sidebar and focus on three main parts of the screen: the **page title** at the top, the main **content area** in the center, and any in-page navigation such as a table of contents or anchor links if they are available on that page. The page title helps you confirm you are in the correct section. The content area shows the full draft text, headings, images, and structured content blocks. If the page includes anchor navigation, use it to jump between sections and confirm that longer pages are easy to scan.

To review the full documentation flow, continue through nearby pages using the sidebar or any **previous** and **next** page controls that appear around the content. This is especially helpful when you want to check whether a setup guide leads naturally into a reference page, or whether grouped pages are ordered correctly for readers.

Because you are working inside the project workspace, you may also see content that is not yet public. Watch for draft-only indicators, unpublished changes, or workspace-only visibility cues. These signals help you distinguish between content that is ready for release and content still being edited. If a page appears unfinished, check whether headings are missing, sections are incomplete, or links point to pages that are still being prepared.

[SCREENSHOT: Documentation page inside a project workspace with sidebar navigation, page title, and content area]

## Exploring API reference pages for endpoints and schemas
To review technical reference content inside a project, open the **API Reference** area from the project navigation. The left-hand navigation usually organizes entries into groups, such as resource sections, tags, or related endpoint categories. Use these groups to move through the reference in a structured way instead of opening pages one by one at random.

When you open an endpoint page, start at the top of the entry. This area usually gives you the most important summary details first. Look for the **HTTP method** label, the **request path**, and the short operation summary. These items tell you what the endpoint does and how it is categorized. If the page includes authentication details near the top, review those as well so you can confirm whether access requirements are clearly described before release.

As you scroll, inspect the request details in the structured sections of the page. These often include parameter tables and request body details.

| Section | What to review | Why it matters |
|---|---|---|
| Path parameters | Required values included in the URL path | Confirms the endpoint can be used correctly |
| Query parameters | Optional or filtering values | Helps reviewers check search, filtering, or paging behavior |
| Headers | Required request headers | Verifies important request requirements are documented |
| Request body | Input fields and schema structure | Shows whether users can understand what data to send |

Continue to the response area and review the listed **status codes**, response descriptions, and example payload blocks. This is where internal reviewers can confirm whether success and error responses are documented clearly enough. If schema sections are available, use them to check field names, nested structures, and overall completeness before the documentation is published.

[SCREENSHOT: API Reference page showing method label, request path, parameters, request body, and response examples]

## Using project navigation and search to move between docs and reference content
When a project contains many guides and reference sections, search becomes the fastest way to move around. In Atloria, use the workspace or documentation search to find a specific page title, endpoint name, or schema term instead of manually expanding every group in the sidebar. This is especially useful during review sessions when you need to confirm whether a term appears consistently across multiple pages.

Search is not only for finding content quickly. It also helps you test whether users inside the project will be able to locate the right material before release. Try searching for a guide title, a feature name, an endpoint label, and a schema term. If the results are clear and well named, reviewers can move between narrative documentation and API reference content with less confusion.

Use the shared project navigation to switch between the written documentation area and the **API Reference** area. This is an important review step because many projects rely on both types of content together. For example, a setup guide may introduce a workflow, while the API Reference provides the exact request details. Moving between both areas helps you confirm that cross-links make sense and that the documentation feels connected rather than split into unrelated sections.

During review, also test navigation details:

- Open sidebar groups and confirm labels are easy to understand.
- Click internal links and anchor links to make sure they open the expected section.
- Check whether related pages are grouped together logically.
- Compare page names and endpoint titles for consistent wording.

Documentation managers often use this step to audit naming consistency. If a guide uses one term but the API Reference uses another, search results and navigation labels will reveal the mismatch quickly.

## Checking what internal users can see before public release
One of the main benefits of reviewing content inside a project workspace is that internal users can see documentation before it is publicly available. Use this view to compare what is visible in the workspace with the project’s public release state. If a page or API section appears in the project but not in the public documentation, that usually means it is still internal, still in draft, or not yet included in the released version.

This is also the right time to confirm access patterns. Project members may be able to open draft pages, unpublished edits, and in-progress API reference sections, while people outside the project may not see them at all. If you are checking readiness with a manager or administrator, ask them to confirm that the correct team members can open the project workspace and review the same internal content.

As you move through the workspace, verify that recent edits are visible. This includes updated page text, changed endpoint details, revised schemas, and newly added sections. Internal review is most useful when it reflects the latest draft state, so it is worth checking that the content shown in the project matches what your team expects to release later.

Use the page itself to judge readiness. Common signs that content is close to release include:

| Sign | What it suggests |
|---|---|
| No draft marker visible | The page may be closer to final review |
| Complete sections from top to bottom | The content is likely structurally ready |
| Endpoint details include parameters, request body, and responses | The reference entry is more complete |
| Working internal links and anchors | Navigation is ready for reader testing |

Pages still under review often show draft indicators, missing sections, incomplete examples, or placeholder-level structure that has not been fully filled out yet.

## Fixing common issues when pages or API sections do not appear
If you cannot find the **Docs** or **API Reference** area, first make sure you are inside the correct project workspace. It is easy to open the wrong project when several projects have similar names. After confirming the project, check whether your role includes access to internal documentation. If you can open the project but do not see its documentation areas, the issue may be related to your workspace permissions.

If a documentation page does not appear in the sidebar, review the project structure carefully. The page may still be unpublished, moved into another section, or placed under a different parent page than expected. Expand grouped sections in the navigation before assuming the page is missing. If your team recently reorganized the documentation tree, older links or saved expectations may no longer match the current layout.

When an API reference page opens but looks incomplete, review the page content itself. A complete endpoint entry should include a summary near the top and structured sections for request details and responses. If those sections are missing or mostly empty, the source material for that reference may not be complete enough yet for Atloria to show a full entry in the workspace.

If search does not return the result you expect, double-check the exact title or term you are using. Search works best when page titles, endpoint names, and section labels have been saved clearly and consistently.

| Problem | What to check |
|---|---|
| Docs or API Reference missing | Correct project and your access level |
| Page missing from navigation | Unpublished status, moved location, or different section |
| Endpoint page incomplete | Missing summary, request details, or response details |
| Search returns nothing | Saved title, endpoint name, or section label may differ |

If the content still does not appear after these checks, ask a project administrator or documentation owner to confirm the page’s current location and visibility inside the workspace.

## Overview
Atloria lets you review both draft documentation pages and draft **API Reference** content inside a project workspace before anything is publicly released. This internal view is useful when you need to check structure, wording, navigation, and technical completeness in one place. Instead of relying only on the public documentation experience, your team can open the project directly and inspect what readers are likely to see once the release is ready.

The most important distinction to keep in mind is the difference between narrative documentation and API reference content. Narrative pages explain workflows, setup steps, and concepts in a guided format. API reference pages are more structured and focus on endpoint details such as request paths, parameters, request bodies, response codes, and schema information. Inside the project workspace, both can be reviewed side by side so teams can confirm that guides and reference entries support each other.

This document focused on how to:

- Open a project and locate its documentation areas
- Browse draft documentation pages through the project sidebar
- Review API reference sections and endpoint details
- Use search and shared navigation to move between content types
- Confirm what internal users can see before release
- Troubleshoot missing pages, incomplete reference entries, or search issues

If you need a refresher on how published technical documentation behaves outside the project workspace, see [Reading Published API and Technical Documentation](doc:reading-published-api-and-technical-documentation). For the next step in this workflow, continue with [Viewing Technical Entities and Related Reference Details](doc:viewing-technical-entities-and-related-reference-details).

## Prerequisites
Before you start reviewing API reference sections inside a project, make sure you can open the correct project workspace in Atloria and that the project already contains documentation content to browse. You do not need public release access for this task, but you do need access to the internal project area where draft pages and draft API reference entries are available.

You will be able to follow this guide more easily if the following are already true:

- You can sign in to Atloria and open the target project.
- The project includes documentation pages, API reference content, or both.
- Your role allows you to view internal project documentation.
- You know the general project area where your team keeps technical docs.

If you are still getting familiar with technical reference layouts, it helps to first read [Reading API and Technical Reference Pages](doc:reading-api-and-technical-reference-pages). If you need help understanding how technical documentation is organized more broadly inside a project, see [Managing Technical Documentation Browsing Inside Projects](doc:managing-technical-documentation-browsing-inside-projects). And if you want a comparison between internal project views and released documentation views, use [Using API Reference Pages in Published and Project Views](doc:using-api-reference-pages-in-published-and-project-views).

During review, it is helpful to have a clear goal before you begin. For example, you may be checking page order in the sidebar, confirming that endpoint entries include complete request and response details, or verifying that draft-only content is visible only to internal reviewers. Starting with one of those goals makes it easier to move through the workspace efficiently and notice gaps before release.