YouTube API Adds Brand Partner Access: What Upload Integrations Need to Change

On July 7, 2026, YouTube added a new brandPartner part to the Data API's video resource. Upload tools can now establish creator-initiated brand partner access while inserting a video, change the association later, and read the canonical partner channel back from YouTube.

brandPartner carries consent and access consequences. YouTube says an accepted association can give the brand access to non-public performance metrics and let it promote the video through a creator partnerships boost campaign. A publishing flow should explain those consequences and ask the creator to confirm them before sending the field.

This article is a documentation and code-path review, not a live eligibility test. We reviewed YouTube's July 7 revision entry, the current video resource, the insert, update, and list methods, then compared them with Kavenio's current YouTube adapter.

TL;DR for builders

• brandPartner is now accepted as a part by videos.insert, videos.update, and videos.list.
• A write can identify the partner by channelId or channelHandle, but not neither.
• Channel IDs must begin with UC; handles must begin with @.
• YouTube returns only the canonical channelId, even when the request used a handle.
• The association can share non-public performance data and enable paid promotion, so the UI needs explicit language and confirmation.
• Kavenio does not expose this field today. Its current upload session requests part=snippet,status, so support would require a deliberate contract-to-provider change.

What YouTube changed

The new resource shape is small:

type YouTubeBrandPartner = {
  channelId?: `UC${string}`;
  channelHandle?: `@${string}`;
};

YouTube says either channelId or channelHandle must be provided when establishing access. If a handle is sent, the response still contains only the resolved channelId.

That asymmetry matters. Handles are useful input because a creator can recognize @brand. They are a poor canonical key because they can change. Store the returned channel ID as the provider identity and retain the submitted handle only as optional display or audit context.

The new part is available in all three video lifecycle operations:

Add the part during resumable upload initialization

For a resumable upload, the new field belongs in the metadata request that creates the session. The media transfer itself does not change.

A request using a recognizable handle would look like this:

const url = new URL(
  "https://www.googleapis.com/upload/youtube/v3/videos",
);
url.searchParams.set("uploadType", "resumable");
url.searchParams.set("part", "snippet,status,brandPartner");

const response = await fetch(url, {
  method: "POST",
  headers: {
    Authorization: `Bearer ${accessToken}`,
    "Content-Type": "application/json; charset=UTF-8",
    "X-Upload-Content-Length": String(contentLength),
    "X-Upload-Content-Type": contentType,
  },
  body: JSON.stringify({
    snippet: {
      title,
      description,
      categoryId,
    },
    status: {
      privacyStatus: "private",
      selfDeclaredMadeForKids: false,
    },
    brandPartner: {
      channelHandle: "@examplebrand",
    },
  }),
});

This example is derived from the documented resource and resumable videos.insert flow. It has not been executed here against an eligible creator and brand pair.

The safe follow-up is a read using the returned video ID:

const verifyUrl = new URL(
  "https://www.googleapis.com/youtube/v3/videos",
);
verifyUrl.searchParams.set("part", "brandPartner");
verifyUrl.searchParams.set("id", videoId);

const verified = await fetch(verifyUrl, {
  headers: { Authorization: `Bearer ${accessToken}` },
});

Do not mark the association as confirmed merely because session creation returned a Location header. The durable checkpoint is the completed video resource and the partner channel YouTube returns.

This changes more than the request body

YouTube's brand partner access guide says an accepted association allows the brand or its agency to view organic and paid performance metrics in Google Ads and promote the creator's video through a creator partnerships boost campaign. Sharing access also adds a paid-promotion label.

The same guide describes eligibility differences:

• YouTube Partner Program creators can search for a brand when there is no reported deal.
• Other creators can select an existing reported brand deal.
• Brands can also initiate a request after upload, which the creator accepts separately.

The Data API reference documents the resource shape, but it does not spell out every eligibility failure or removal behavior. A production integration should assume YouTube enforces account and deal eligibility server-side and preserve the provider's error response for support. It should not invent client-side promises the API documentation does not make.

The Kavenio boundary today

Kavenio's current YouTube publishing contract accepts title, visibility, made-for-kids status, synthetic-media status, category, tags, thumbnail, playlist, subscriber notification, and a first comment.

The provider adapter builds this metadata:

{
  snippet: {
    title,
    description,
    tags,
    categoryId,
  },
  status: {
    privacyStatus,
    selfDeclaredMadeForKids,
    containsSyntheticMedia,
  },
}

It initializes the resumable session with:

part=snippet,status

There is no brandPartner field in the public contract and no provider translation for it. Because the platform-data schema is strict, clients cannot smuggle the new object through as an undocumented extra property.

That is the correct boundary to state publicly: YouTube now supports the capability; Kavenio does not expose it yet.

What implementation would require

This is a small provider payload but a full vertical slice:

1. Add a public brandPartner input with exactly one of channelId or channelHandle.
2. Validate the UC and @ prefixes before making the provider call.
3. Require an explicit confirmation that performance data will be shared with the partner.
4. Add brandPartner to the resumable initialization part list only when requested.
5. Return the canonical partner channelId from the completed video resource.
6. Preserve YouTube eligibility and permission errors as provider-aware domain errors.
7. Cover handle input, channel-ID input, invalid prefixes, both fields, neither field, and provider rejection in tests.
8. Document that brand-initiated requests remain a separate workflow.

A normalized API should not hide the provider's consent semantics. The field may live beside other YouTube publishing options, but it needs stronger UI copy than a category or tag input.

What breaks in production

Treating the submitted handle as permanent identity

YouTube resolves a handle and returns a channel ID. Persist that ID. A handle is user-facing input, not a stable foreign key.

Updating multiple parts with partial objects

The videos.update method replaces mutable values in every part named by the request. If an integration includes snippet or status while sending only a brand partner change, omitted values can be removed or reset.

Fetch the current resource before a multi-part update, or update only brandPartner when that is the only intended change.

Assuming every creator can start every association

The Studio workflow distinguishes YPP creators from other creators and distinguishes new brand searches from existing reported deals. The API addition does not erase those eligibility rules.

Reporting success before verification

A successful metadata request or upload-session creation does not prove the final video carries the intended association. Verify the completed video with videos.list(part=brandPartner).

Hiding the data-sharing consequence

Brand partner access is not just attribution. YouTube says it can share non-public metrics including reach, watch time, engagement, and audience demographics. The creator should understand that before the integration sends the field.

The practical takeaway

YouTube has moved creator-initiated brand partner access into the same API lifecycle as upload, edit, and read. That is useful for products managing sponsored video workflows because creators no longer need a separate manual Studio step for every supported association.

The API surface is compact. The product work is consent, identity normalization, eligibility errors, and read-after-write verification.

Kavenio's YouTube publishing guide covers the upload behavior available today. Brand partner access is not yet part of Kavenio's public posting contract; this change is the implementation boundary we would use if we add it.