> ## Documentation Index
> Fetch the complete documentation index at: https://docs.newport.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Key Concepts: How the Google Platform Is Structured

> Learn the core terminology and concepts behind Google, including workspaces, projects, users, integrations, API keys, and the platform data model.

Before you dive deep into building with Google, it's worth taking a few minutes to understand how the platform is structured. The concepts covered on this page appear throughout the documentation, the dashboard UI, and the API — and having a clear mental model of how they fit together will save you time, prevent confusion, and help you make better architectural decisions for your team.

## Workspaces

A **workspace** is the top-level organizational container in Google. Think of it as the home base for your entire team or organization. Every resource you create — projects, records, integrations, and API keys — lives inside a workspace. When you sign up, Google automatically creates your first workspace, and you can create additional ones for separate teams, departments, or clients as needed.

Workspaces are isolated from one another: data in one workspace cannot be accessed by members of another unless you explicitly set up cross-workspace integrations. Each workspace has its own settings, member list, billing, and usage quota.

## Projects

**Projects** are how you organize focused bodies of work within a workspace. A project might represent a product, a campaign, a dataset, or any logical grouping that makes sense for your team. Each project contains its own set of **records** — the individual data entries, tasks, documents, or items your team creates and manages.

Projects let you:

* Define a scope of work with clear ownership and membership
* Apply project-specific permissions on top of workspace-level roles
* Track progress, activity history, and API usage scoped to that project
* Connect integrations that apply only to that project's context

## Users & Roles

Google uses a role-based access control (RBAC) model to manage what different people can see and do within a workspace. Every workspace member is assigned one of three roles:

<Tabs>
  <Tab title="Admin">
    **Admins** have full control over the workspace. As an Admin you can:

    * Invite and remove workspace members
    * Assign and change member roles
    * Create, archive, or delete any project
    * Manage billing, subscription, and workspace settings
    * Generate and revoke API keys (including other users' keys)
    * Access all records and data across every project
    * Configure integrations and manage OAuth connections

    The person who creates a workspace is automatically assigned the Admin role. Every workspace must have at least one Admin at all times.
  </Tab>

  <Tab title="Editor">
    **Editors** can create and modify content but cannot manage workspace membership or billing. As an Editor you can:

    * Create, update, and delete records within projects you have access to
    * Create new projects and manage projects you own
    * Connect personal integrations to projects you belong to
    * Generate and manage your own API keys
    * View workspace activity logs for your own projects
    * Invite guests to specific projects (with Admin approval, if enabled)

    The Editor role is the default for most team members who are actively contributing to projects.
  </Tab>

  <Tab title="Viewer">
    **Viewers** have read-only access to the workspace resources they've been granted access to. As a Viewer you can:

    * Browse and read records in projects you've been added to
    * View project activity history and timelines
    * Export data from projects (if the workspace export policy permits it)
    * Generate personal API keys scoped to read-only operations
    * Subscribe to notifications and updates for watched projects

    The Viewer role is ideal for stakeholders, clients, or external collaborators who need visibility without the ability to make changes.
  </Tab>
</Tabs>

## Integrations

**Integrations** are pre-built connectors that link Google to the external tools and services your team already uses. Rather than switching between a dozen different apps, integrations surface data and actions from those services directly inside your workspace.

Google supports two categories of integrations:

* **OAuth integrations** — Authenticated via a standard OAuth 2.0 flow. You click **Connect**, authorize access in the external service, and Google receives a scoped access token. Examples include Google Drive, Slack, GitHub, and Salesforce.
* **Webhook integrations** — Google can push real-time event notifications to a URL you register. When an event occurs in your workspace, Google sends an HTTP POST to your endpoint so your systems can react immediately. You manage webhook subscriptions via the [Webhooks API](/api/webhooks).

Once an integration is connected, its data appears as records within your chosen project and is fully queryable via the Google API.

## API Keys

**API keys** are secret tokens that authenticate programmatic requests to the Google REST API. Every API call must include a valid key in the `Authorization` header using the `Bearer` scheme.

Key characteristics of Google API keys:

* Each key is scoped to a specific workspace and optionally restricted to certain permission levels (read-only, read-write, or admin)
* Keys can be labeled, rotated, and revoked at any time from **Settings → API Keys**
* API usage is logged per key, giving you full visibility into how and when the API is being called
* Rate limits are applied per key; consult the [API Reference](/api/introduction) for current limits

<Warning>
  Treat your API keys like passwords. Never embed them in client-side code, commit them to version control, or share them via unencrypted channels. Use environment variables or a secrets manager to inject keys at runtime.
</Warning>

## Data Model

Google's data model follows a clear hierarchy that maps directly to both the UI and the API:

```
Workspace
└── Projects
    └── Records
        └── Fields (key-value attributes on a record)
```

* A **Workspace** contains one or more **Projects**.
* Each **Project** contains one or more **Records** — the individual data units (tasks, documents, entries, etc.).
* Each **Record** has a set of **Fields** that store typed values: text, numbers, dates, references to other records, or rich content.

Relationships between records are expressed as reference fields, allowing you to model one-to-many and many-to-many relationships natively inside Google without custom database logic.

<Note>
  Every concept described on this page has a direct counterpart in both the dashboard UI and the API. Users are managed via the [Users API](/api/users), data records via the [Data API](/api/data), and integrations via the [Integrations API](/api/integrations). Keeping this mapping in mind makes the API Reference much easier to navigate.
</Note>