Way to modify draft api , by making sure that all fields remain intact

[praneetharao0994]

I want to modify the ANS object by adding new fields under additional_properties, and I’m using the Draft API’s PUT method to update the ANS payload. However, when doing this, some fields from the original article—such as authors, creation_date, and content_restrictions—get dropped. In other cases, I run into errors because certain fields aren’t allowed in the ANS payload.

What’s the correct way to use the Draft API so that I can update additional_properties without losing existing fields or triggering validation errors? Is there a recommended approach to handle this?

[radominchev]

Updating additional_properties with the Draft API (without breaking ANS)

Here’s a straightforward way to safely update additional_properties on a story using the Draft API, without losing fields like authors or running into validation errors.

---

What’s going wrong

You’re seeing two things:

1. Fields disappear (authors, content_restrictions, etc.)
   When you call:

   PUT /draft/v1/story/{id}/revision/draft
   Content-Type: application/json
   
   {
     "ans": { ... }
   }

   the Draft API treats that as: “replace the draft’s ANS with whatever you send”. If you only send a partial ANS (for example, mainly additional_properties and a few fields), anything you don’t include (like credits.by for authors or content_restrictions) can be dropped in the new revision.

2. Some fields cause Draft API errors
   The Draft API does not allow certain circulation/URL fields to be present in the ANS body on write. If they are present, you’ll get errors. These typically include:

   • websites
   • canonical_url
   • taxonomy.sections
   • taxonomy.sites
   • taxonomy.primary_section
   • taxonomy.primary_site

   Those fields are managed via circulation endpoints (for example /draft/v1/story/{id}/circulation/{website}), not via the ANS in /revision/draft.

3. Some fields are system-managed
   Fields like:

   • created_date
   • last_updated_date
   • first_publish_date

   are system-generated. The Draft API ignores any values you send for them and sets its own.

---

The correct pattern to update additional_properties

The safest and recommended way is:

1. GET the current draft ANS

GET /draft/v1/story/{id}/revision/draft
Authorization: Bearer <TOKEN>

Use the ans from this response as your starting point. This ensures you’re working with the exact shape that the Draft API expects.

2. Strip forbidden circulation/URL fields (if present)

Before sending the ANS back, remove any fields that Draft API doesn’t accept in the body:

// Start with the ANS from GET /revision/draft
const ans = response.ans;

// Remove circulation-related fields that Draft API rejects on write
delete ans.websites;
delete ans.canonical_url;

if (ans.taxonomy) {
  delete ans.taxonomy.sections;
  delete ans.taxonomy.sites;
  delete ans.taxonomy.primary_section;
  delete ans.taxonomy.primary_site;
}

Do not remove normal content fields like credits, content_restrictions, headlines, etc. Those need to stay so they’re preserved on the new revision.

3. Merge your additional_properties changes

Now safely add or update your custom fields under additional_properties:

ans.additional_properties = {
  ...(ans.additional_properties || {}),
  my_integration: {
    ...(ans.additional_properties?.my_integration || {}),
    foo: "bar",                 // your new custom field(s)
    updated_at: new Date().toISOString()
  }
};

Key idea: you are merging into the existing object instead of replacing it entirely. That way any other keys under additional_properties are preserved.

4. PUT the full ANS back to Draft API

Finally, send the updated ANS back:

PUT /draft/v1/story/{id}/revision/draft
Authorization: Bearer <TOKEN>
Content-Type: application/json

{
  "ans": ans
}

Optionally, you can use the etag from the GET response with an If-Match header to avoid overwriting someone else’s newer changes:

PUT /draft/v1/story/{id}/revision/draft
Authorization: Bearer <TOKEN>
If-Match: W/"<etag-from-get>"
Content-Type: application/json

{
  "ans": ans
}

If the ETag doesn’t match, Draft API will return a precondition error. In that case you:

1. GET the draft again,
2. Re-merge your additional_properties changes,
3. PUT again with the new ETag.

---

have a look at the following docs
Best, Rado

[praneetharao0994]

Thankyou Rado !!. WIll try this out

[praneetharao0994]

this worked