Review and approval

Your client reviews posts in your own product. Native records each decision and checks it again when the post is scheduled or published.

An approval names one exact version of a post. Every post carries a contentDigest, a stamp of everything that would be published. approve_post records the digest the reviewer saw. When the post is scheduled or published, Native works out the digest again. If the content has changed since the approval, the approval no longer counts.

1. Read the post with view_post. Keep its contentDigest.
2. Show the reviewer every destination in destinations[]: the caption, first comment, title, images, video cover and publishing options. The preview card alone is not the whole post.
3. Call approve_post with expectedDigest set to the contentDigest from that same read, and name the reviewer. Or call reject_post with their reason.
4. Schedule or publish the post. Native checks the decision again at that moment. See scheduling and publishing.

Approve only once every image has landed. A picture that is still rendering changes the digest when it arrives, and the approval is then stale.

New, in development: created items in get_post_batch_status, the result of create_draft, and get_post_status will carry the same contentDigest and approval as view_post. You will then be able to show and approve a new post without reading it again. Until that ships, read the post with view_post first.

contentDigest is an opaque string. Today it looks like v3. followed by a SHA-256 hash, but the format can change. Compare it only for equality.

It covers which destinations the post has and, for each destination:

• the caption
• the first comment
• the publishable title
• the video cover (thumbnailUrl)
• the publishing options, such as a Reddit subreddit or TikTok visibility
• the image URLs, in order
• the alt text of its pictures, when any picture on that destination has some (new, in development)
• the post’s own title, on a LinkedIn or TikTok destination without a title of its own (new, in development)
• the subtitle files sent with its videos

It does not cover the scheduled time. Moving a post to another time keeps its approval.

Any edit changes the digest, whichever way it is made: through this API, in the Native app, or by Native’s own image workers. Adding or removing a destination changes it too. A changed image always has a new URL, so it always gives a new digest.

view_post.destinations[] shows everything the digest covers except the subtitle files, which this API does not return. On a video post, a subtitle change rolls the digest even though nothing you can show the reviewer has changed. If you review video posts, you cannot show their subtitles from this API yet.

New, in development: the same goes for the post’s own title. A LinkedIn or TikTok destination without a title of its own publishes the post’s title instead, and a LinkedIn one falls back to the brand’s name when the post has no title. destinations[] shows each destination’s own title and options, not the post’s title, so a change to the post’s title in the Native app can make an approval stale with nothing new to show.

Records approval of the post’s exact current content.

If you send neither reviewer field, Native records the caller as the reviewer. It records the caller beside the reviewer either way.

const viewed = await client.callTool(
  { name: "view_post", arguments: { id: postId } },
  undefined,
  { timeout: 150_000 },
);
const post = (viewed.structuredContent as { data: any }).data;

// Show post.destinations to the reviewer. When they approve:
const result = await client.callTool(
  {
    name: "approve_post",
    arguments: {
      id: postId,
      expectedDigest: post.contentDigest,
      reviewerName: "Kari Nordmann",
      reviewerEmail: "kari@example.com",
    },
  },
  undefined,
  { timeout: 150_000 },
);

const data = (result.structuredContent as { data: any }).data;
if (result.isError) {
  if (data.error.code === "post_content_changed") {
    // The post changed after the reviewer saw it.
    // Read it again and show it to them again.
  }
} else {
  console.log(data.approval.valid); // true
}

Never resend with a fresher digest that the reviewer did not see. If the post changed, show it again and let them decide again.

The rest of the post comes back too, without a declared schema: title, status, scheduledAt, companyId, brandId, owner, origin, groupKey, platformVariants[] with captions as plain text, createdAt and updatedAt. Ignore any field you do not use.

Any tool can also return the common codes, such as internal_error or upstream_timeout. They are listed under errors.

Records a rejection with a reason. While the latest decision is a rejection, schedule_post and publish_post_now refuse the post with approval_rejected.

Editing the post does not clear a rejection. Only a new approve_post does, so the post needs a fresh review after it is fixed.

Reviewer identity works as in approve_post. The output has the same shape as approve_post’s, with approval.decision set to REJECTED.

The latest decision on a post has the same shape everywhere it appears: in view_post, in the results of approve_post and reject_post, and (new, in development) in get_post_status, create_draft and created get_post_batch_status items. It is null until someone records a decision.

{
  "decision": "APPROVED",
  "reviewerName": "Kari Nordmann",
  "reviewerEmail": "kari@example.com",
  "reason": null,
  "decidedAt": "2026-11-02T08:14:03.000Z",
  "approvedDigest": "v3.9f2c41d07a6b3e58c1d4f0a92b7e6c35d8a1f4e07b29c6d3a5e8f1b0c47d2a96",
  "valid": true
}

Each time a post is scheduled or published, Native works out its digest again and compares it with the latest decision.

All of these codes have retryable: false: something has to change before the same call can succeed.

schedule_post and publish_post_now refuse the whole call. reschedule_posts checks each post on its own: a refusal shows up in that entry’s moves[].error, and the other entries still run. See scheduling and publishing.

Today, a post with no decision on record can be scheduled and published on every workspace. If your product promises that nothing goes out without the client’s approval, enforce that on your side until approval_required ships.

On a workspace that requires approval, nothing Native does will change approved content:

• No design re-render. A post whose design is stale is refused, not re-rendered.
• No media repair, such as copying pictures from the main design onto a destination.
• No re-crop.
• No silent re-approval when someone presses Schedule in the Native app. The schedule fails with approval_stale, and the app asks for an explicit approval.
• A LinkedIn document PDF is built from the approved images.
• A branding change never re-renders a post that already exists, approved or not.

The one change Native still makes is format conversion, for example to JPEG for Instagram. Where any other change would be needed, the publish is refused with design_changed_after_approval and nothing is sent.

No tool renders a stale design on its own. An edit that re-renders the design, such as generate_image, produces new pictures. These pages do not cover generate_image yet: tools/list has its schema. Read the post again with view_post, have the new pictures reviewed, and approve the post again.

• Keep the digest you showed next to the decision in your own records. It tells you later exactly which version the client approved.
• Name the reviewer with reviewerName and reviewerEmail. Without them, the record names the caller, not the person who decided.
• Read approval.valid before you schedule. false means the content changed after the decision.
• After any edit, show the post again and ask for a new approval. update_post, generate_caption, regenerate_post_image and changes to the destinations all change the digest.
• Pass a rejection’s approval.reason to whoever fixes the post.