Update an existing request with complete replacement of editable fields

Updates an existing request by replacing all editable fields with the provided values. This is a full update
operation that replaces the request's content while preserving its identity and system-managed metadata. Only
users with appropriate management permissions can update requests.

Key Features:

  • Updates request content including title, description, dates, and priority
  • Allows reassigning requests to different users with validation
  • Maintains activity tracking and updated timestamps for modified requests
  • Validates assignee user IDs to ensure valid assignments
  • Returns updated request object with new timestamps and content
  • Preserves request identity and system metadata

Authorization Logic:

  1. User must have a valid JWT token with program management scopes
  2. Token must be valid for this operation
  3. User must have permission to update requests in the specified space
  4. Assignee user must exist and be valid within the tenant

Usage Example:

Update request details when requirements change, reassign to different team members, or modify deadlines to reflect updated program schedules.

Path Params
string
required
length between 7 and 22

The unique identifier of the space containing the target entity. This determines the scope of entity queries and ensures proper access control. The space must be accessible to the authenticated user with appropriate permissions. It can be the unique identifier (GUID) of the space or the word "default" to indicate the default programs space. Common values include "default" and "rkr83lapKkyCJuLLWqLqzB".

string
required

The unique identifier of the request to update. The request must exist within the specified space and the user
must have appropriate permissions to modify it.

Body Params

The request data

string | null

Unique identifier of the user to whom this request is assigned for completion and ownership. Accepts user IDs in either base64url-encoded format (URL-safe base64 using A-Z, a-z, 0-9, dash, underscore without padding, example 'u7YtMp2kQxRvN9LmW4HzAg') or GUID format (128-bit identifier with hyphens, example '56d7d33f-1d42-461b-85eb-26b7b2872c88'). Use this field to delegate request responsibility to specific team members, track workload distribution, and enable assignee-based filtering and notifications. Set to null to explicitly unassign the request, leaving it available for manual assignment or routing. When updated, the system typically sends assignment notifications to the new assignee and updates the request in their work queue. Assignee must have appropriate permissions to view and work on requests in the specified space. Changing assignee does not affect request status or other properties unless workflow rules trigger additional actions.

string | null

Human-readable title or name of the request providing a concise summary of what is being requested or the work to be completed. This string field serves as the primary identifier in UI listings, search results, notifications, and reports, helping users quickly understand request purpose without viewing full details. Use clear, descriptive titles that communicate the request's objective such as 'Create Q1 Product Launch Materials', 'Review Sales Enablement Content', or 'Update Customer Training Documentation'. Typical length ranges from 5-100 characters for optimal display across interfaces. Set to null to leave the title unchanged during partial updates, or provide new text to update the request name. Title changes are immediately reflected in all views and may trigger update notifications to followers and assignees.

int32 | null

Integer identifier of the workflow step or status stage that represents the request's current position in the approval or completion workflow. Step IDs correspond to predefined workflow stages in the request form's status schema such as Submitted (step 1), In Review (step 2), Approved (step 3), In Progress (step 4), or Complete (step 5). Use this field to advance requests through workflow stages, update status programmatically, or route requests to different processing queues based on stage. The specific step ID values and their meanings are defined by the statusSchema configuration for the request's form. Set to null to leave status unchanged. Changing stepId typically triggers workflow automation including notifications, status change events, and conditional field updates. Ensure the provided stepId exists in the form's configured status schema to avoid validation errors. Example values like 3 for 'Approved' or 5 for 'Complete' depend on your organization's workflow configuration.

string | null

Unique identifier of the program that this request is associated with or belongs to, enabling requests to be linked to larger program initiatives for tracking, reporting, and organizational purposes. Accepts program IDs in base64url-encoded format (example 'xH75yTE6xmz6MUvcTDxIRi') or GUID format (example '12345678-1234-1234-1234-123456789abc'). Use this field to associate requests with programs for program-level reporting, dependency tracking, and initiative alignment. When a request is linked to a program, it appears in the program's request list and contributes to program metrics and completion tracking. Set to null to disassociate the request from any program, making it a standalone request. Program must exist in the same space and user must have permissions to associate requests with it. Changing programId updates program associations immediately and may affect program metrics and dashboards.

string | null
enum

Priority level classification indicating the relative urgency and importance of the request for resource allocation and completion sequencing. Allowed values are 'low' (routine requests with flexible timelines), 'medium' (standard priority for typical requests), 'high' (important requests requiring expedited attention), or 'critical' (urgent requests needing immediate action and highest resource priority). Use priority to influence work queue ordering, enable priority-based filtering and reporting, and communicate urgency to assignees and stakeholders. Priority typically affects default sort order in work lists, notification urgency, SLA calculations, and escalation thresholds. Set to null to leave priority unchanged during updates. Changing priority may trigger notifications to assignees and followers, update dashboard metrics, and influence automated routing decisions. Example use case includes escalating priority from 'medium' to 'critical' when customer deadlines accelerate.

Allowed:
date-time | null

Planned or scheduled date and time when work on this request is expected to begin in ISO 8601 format with timezone (example '2025-02-01T09:00:00Z' for February 1, 2025 at 9:00 AM UTC). Use this field for request scheduling, timeline planning, capacity allocation, and start date tracking in calendar views and Gantt charts. The start date helps with workload planning, dependency management, and identifying requests that should be in progress. Set to null to clear the planned start date or leave it undefined. When both plannedStartDate and plannedEndDate are set, the system can calculate request duration and detect schedule conflicts. Changing the start date updates timeline visualizations immediately and may trigger rescheduling notifications. Common patterns include setting start dates to align with sprint boundaries, program phases, or resource availability windows.

date-time | null

Planned completion date and time (due date) when this request is expected to be finished and delivered in ISO 8601 format with timezone (example '2025-02-15T17:00:00Z' for February 15, 2025 at 5:00 PM UTC). This field serves as the deadline for request completion, enabling due date tracking, overdue identification, SLA monitoring, and timeline visualization in calendar and Gantt views. Use for setting completion expectations, tracking on-time delivery metrics, and triggering deadline-based notifications. Set to null to remove the due date constraint or leave it undefined. The system often highlights requests approaching or past their plannedEndDate to prompt timely completion. When combined with plannedStartDate, enables duration calculations and schedule optimization. Common use cases include aligning end dates with program milestones, customer commitments, or campaign launch dates.

int32 | null

Estimated time required to complete the request measured in days (integer value representing full calendar days). Use this field for effort estimation, capacity planning, workload forecasting, and duration-based scheduling. When set along with plannedStartDate, the system can automatically calculate plannedEndDate, or vice versa to maintain consistency between start, end, and duration. Typical values range from 1 (quick requests completing in one day) to 30+ days for complex multi-week initiatives. Set to null to leave duration unspecified or remove duration constraints. Duration helps with resource allocation, identifying time-intensive requests, and generating capacity reports. Common patterns include setting standard durations for request types like 3 days for content reviews or 10 days for major deliverables, enabling predictable scheduling and throughput planning.

string | null

Textual note or message providing context, explanation, or commentary about the request update, particularly useful when changing status, priority, or assignments. This note field is typically included in system-generated notifications sent to assignees, followers, and stakeholders when the request is updated, helping recipients understand the reason for changes or additional context about the request state. Use for communicating update rationale such as 'Priority increased due to customer escalation', 'Reassigned based on subject matter expertise', or 'Extended due date pending stakeholder approval'. Set to null to update the request without adding explanatory notes. Notes appear in notification emails, activity feeds, and audit logs providing transparency about why changes were made. Typical length ranges from one sentence to a short paragraph (10-200 words) to maintain readability in notifications.

customProperties
array of objects | null

Array of custom property values providing organization-specific metadata, categorization, and extended attributes for the request beyond standard fields. Each CustomPropertyValuesInput object in the array specifies a custom property ID and its corresponding value (text, number, date, dropdown selection, or multi-select values depending on property definition). Use custom properties to capture domain-specific information like Department, Project Code, Budget Category, Customer Segment, Region, or any custom taxonomy defined in your organization's workspace configuration. Custom properties enable advanced filtering, reporting, and analytics tailored to your business needs. Set to null or empty array to leave custom properties unchanged during partial updates, or provide array of property updates to modify specific custom field values. Custom property IDs must correspond to properties defined in the request form's configuration. Example includes setting Department property to 'Marketing' or Project Code to 'LAUNCH-2025-Q1'.

customProperties
contentRefs
array of objects | null

Array of content references linking this request to related documents, presentations, assets, or other content items stored in Seismic's WorkSpace or DocCenter repositories. Each ContentRef object contains a content item identifier and repository type (WorkSpace for editable content, DocCenter for published content library items). Use content references to associate requests with deliverables they produce, source materials they depend on, or related resources for context. Content associations appear in request detail views, enable content-based reporting, and provide quick access to related materials for assignees. Set to null or empty array to leave content associations unchanged, or provide array of ContentRef objects to update the list of associated content items. Common use cases include linking a content creation request to the draft document being developed or associating review requests with the content being reviewed.

contentRefs
formRef

Reference to the request form definition that structures this request's fields, workflow, custom properties, and validation rules. The FormReference object contains the form's unique identifier and metadata linking the request to its governing form template. Request forms define what fields are available, what workflow steps are valid, which custom properties can be set, and how the request behaves throughout its lifecycle. Changing formRef is typically uncommon as it redefines the request's structure, potentially affecting field availability, workflow stages, and custom property definitions. Use with caution as form changes may require data migration or field remapping. Set to null to disassociate from a specific form (reverting to default request behavior) or provide a new FormReference to transition the request to a different form template. Most updates leave this field unchanged.

Responses

Language
Response
Click Try It! to start a request and see the response here! Or choose an example:
application/json