---
category: [Administration & Integrations, Administration & Integrations/Custom Integrations & Apps, Platform and Product Extensions, Platform and Product Extensions/Workday Extend]
keyword: [Extend, Workday Graph API, Graph API, GraphQL, Graph API headers]
nav: wcp_docs
parent_url: /wcp_docs/
title: Graph API Headers
layout: subsection
---
Graph API supports these HTTP headers, enabling features related to the queries or mutations you submit with the Graph API endpoint.
## Validate Only Header
The HTTP header `x-validate-only` enables you to reduce the required corrections and protect data integrity when updating data with Graph API. When you set `x-validate-only` to 1, Graph API only validates the request and doesn't update the tenant data. The Graph API response adds an extensions object with the `validateOnly` property containing the `isSuccess` field, which indicates the validation result.
In this example, we submit the Graph API endpoint with this HTTP request header:
```
x-validate-only: 1
```
The valid values are:
- `1`: Enables the validate-only mode, which doesn't update the tenant data.
- `0`: Updates the tenant data. If you don't specify the `x-validate-only` header, `0` is the default.
The sample request submits this mutation:
```
mutation createMyExpenseReport($createExpenseReport_input: Expense_ReportPostServiceRepresentation_CreateInput!) {
createExpenseReport(input: $createExpenseReport_input) {
descriptor
workdayID {id}
}
}
```
The input variable for the sample mutation contains an invalid date, which causes a validation error:
```
{
"createExpenseReport_input": {
"expenseReportMemo": "Group lunch",
"creationDate": "2023-09-31"
}
}
```
The error response includes the extensions object with the `validateOnly.isSuccess` field:
```
{
"data": {
"createExpenseReport": null
},
"errors": [
{
"message": "INVALID DATE during parsing. Failed to parse ISO-8601 date",
"path": [
"createExpenseReport"
],
"locations": [
{
"line": 2,
"column": 3
}
],
"extensions": {
"code": "S5",
"path": [
"creationDate"
],
"field": "creationDate",
"statusCode": 400
}
}
],
"extensions": {
"validateOnly": {
"isSuccess": false
}
}
}
```
## Warning Action Header
By default, validation errors from Graph API mutations prevent data from being saved. If a mutation performs validations that return warnings instead of critical errors, you can use the HTTP header `wd-warning-action` to control whether data should persist.
The `wd-warning-action` header enables applications to:
- Save data even if warning-level validations fail.
- Add business logic to bypass non-critical warnings while still enforcing strict requirements for critical errors, enabling applications to differentiate between critical blockers and informative warnings.
Example: Display a message to users, preventing them from being blocked by a warning about minor data issues that do not violate core business integrity.
To persist the data when a mutation validation fails with a warning, set the `wd-warning-action` header value to `updateonwarning`.
Example:
```
wd-warning-action: updateonwarning
```
In this example, the `requestLeaveOfAbsence` mutation request includes the `wd-warning-action: updateonwarning` header value and encounters a validation warning. This sample response includes updated data response with the returned warning:
```
{
"data": {
"requestLeaveOfAbsence": {
"businessProcessParameters": {
"for": {
"descriptor": "Abs_Emp2_ 7563072 (On Leave)",
"workdayID": {
"id": "7a61a4019a860100228fb0c7543d0000"
}
},
"overallBusinessProcess": {
"descriptor": "Absence Request: Abs_Emp2_ 7563072 (On Leave)",
"workdayID": {
"id": "7a61a4019a86010023b2695eab200000"
}
},
"overallStatus": "In Progress",
"transactionStatus": {
"descriptor": "In Progress",
"workdayID": {
"id": "e2d08afc53614c37b32b31270bb8bee3"
}
},
"warningValidations": null
},
"descriptor": "Absence Request: Abs_Emp2_ 7563072 (On Leave)",
"estimatedLastDayOfLeave": "2027-05-01",
"firstDayOfLeave": "2027-02-06",
"lastDayOfWork": "2027-02-05",
"leaveType": {
"descriptor": "00001191173700 - 2026 03 10 13 31 21 168 -0700 > 222221894363407 - 2026 03 10 13 31 25 715 -0700",
"workdayID": {
"id": "7a61a4019a86010022b21f3e92420000"
}
},
"workdayID": {
"id": "7a61a4019a86010023b2695eab200000"
}
}
},
"extensions": {
"warnings": [
{
"message": "Leave Type validation is violated: Sufficient Balance Exists",
"code": "A3243"
}
]
}
}
```
Consider these guidelines:
- The only valid header value is “`updateonwarning`”. An invalid or null value returns an error.
- A misspelled header name results in the default behavior. By default, a warning returns an error response without data persistence.
- A critical validation failure is a critical error that stops processing and blocks data persistence, regardless of warning validations and the `wd-warning-action` setting.
- To ensure data integrity and system efficiency, the Graph API framework performs validation checks in a specific sequence. The framework immediately stops processing and returns an error as soon as the first critical validation failure occurs. Subsequent validation levels will not be evaluated until the preceding errors are resolved.
- The warnings themselves don’t persist as part of the business object. If you need an audit trail of warnings, capture them from the error response.
- The `wd-warning-action` and `x-validate-only headers` are mutually exclusive. You can’t use both headers in the same REST API request, even if `x-validate-only:0`.