# Update Page via Write API (Full Update)

Update existing pages using PUT requests. PUT behaves identically to PATCH (partial update), allowing you to update only the fields you specify while preserving unchanged content.

Page Type Flexibility: Use * to update pages across all page types when you know the slug but not the specific type, or specify the particular page type slug for optimized queries.

Partial Update Behavior: Include only the fields you want to modify in your request body. All other fields will retain their current values, making this ideal for targeted content updates without affecting the entire page structure.

Locale Handling: For single-locale updates, use the direct field format. For multi-locale organizations, nest your field changes under the appropriate locale codes. You can update specific locales without affecting others.

Status Control: Control page visibility by setting status to "draft" (keeps the page unpublished) or "published" (makes changes live immediately). Draft status is useful for staging content changes.

Immutable Fields: Page title and slug cannot be modified via PUT requests to maintain URL consistency and prevent broken links. These core identifiers must remain stable after page creation.

Repeater Field Behavior: When updating repeater fields, you must include the complete array contents in your request. Partial repeater updates are not supported - the entire repeater will be replaced with your provided data.

Scheduling Limitation: Page scheduling is not available through the Write API. Any scheduled parameters in your request will be ignored, allowing you to safely update pages that are currently scheduled without affecting their publication timing.

Endpoint: PUT /pages/{page_type}/{page_slug}/
Version: 2.0.0
Security: writeTokenAuth

## Path parameters:

  - `page_type` (string, required)
    The type of page to update.

- Use * to search across all page types
- Use a specific page type slug to limit search to that type

  - `page_slug` (string, required)
    The slug of the page to update.
    Example: "faq"

## Query parameters:

  - `locale` (string)
    Set to the API slug of a pre-configured locale (e.g., 'en' or 'fr').

Usage: Only applicable when using the single-locale request format (WITHOUT Locales format).
If you are using the single-locale format to update only a single locale's version of a page, you can specify the locale via this query param, e.g., ?locale=en.

Not applicable when using the multi-locale format (WITH Locales format), as locale codes are specified within the request body under the fields object.

When omitted and using single-locale format, updates the organization's default locale.
    Example: "en"

## Request fields (application/json):

  - `title` (string)
    The title of the page. Note: This field cannot be updated via PATCH - it's included here for documentation completeness only.

Alternative: You can also use name which will be automatically converted to title.

  - `status` (string)
    Status of the update. Can be 'draft' or 'published'. Defaults to 'draft'. Setting to 'published' will make your update live immediately.

Note: If scheduled timestamp or status is passed, these fields will be ignored to allow updating already scheduled pages.
    Enum: "draft", "published"

  - `fields` (object)
    Flexible Fields Object - Two Supported Formats
- Format 1: Single-locale/direct fields
  - fields contains field names as keys (e.g., headline, questions).

- Format 2: Multi-locale
  - fields contains locale codes as keys (e.g., en, es, fr).

- Detection: The system automatically detects the format based on whether the
  top-level keys are locale codes or field names.

- Partial update behavior
  - Only specify the fields you want to update; omitted fields remain unchanged.
  - Repeater fields must be replaced in full; delta changes are not supported. If you need
    to clear a repeater, provide an empty array ([]).
  - Images and media can be updated by providing remote URLs.

- Examples: See the Examples section below for sample request bodies.

## Response 202 fields (application/json):

  - `status` (string)
    Indicates that the page update request has been accepted and is being processed asynchronously
    Enum: "pending"

## Response 401 fields (application/json):

  - `detail` (string)
    Error message describing what went wrong
    Example: "Authentication credentials were not provided"

## Response 403 fields (application/json):

  - `detail` (string)
    Error message describing what went wrong
    Example: "Authentication credentials were not provided"

## Response 404 fields (application/json):

  - `detail` (string)
    Error message describing what went wrong
    Example: "Authentication credentials were not provided"