---
title: "Creator Partnership Brand Kit Endpoint"
method: POST
path: "/api/v1/remy/creator-partnership/brand-kit"
tags: ["remy", "remy"]
---

# Creator Partnership Brand Kit Endpoint

`POST /api/v1/remy/creator-partnership/brand-kit`

Public brandbooster.ai/creator-partnership Recognized/Elite form — same base fields as the
Registered route, plus the T2 brand-kit questions (audience, niche, country, language,
engagement, past collabs, rate per video). Same shared static x-api-key gate as the
Registered route, not a Bearer token.

## Request body

- CreatorPartnershipBrandKitSignupRequestDTO — Submitted from the public brandbooster.ai/creator-partnership Recognized/Elite form — same base fields as the Registered intake, plus the T2 brand-kit questions.
  - `name` string, required
  - `email` string, email, required
  - `profile_link` string, required
  - `plan` 'registered' | 'recognized' | 'elite', required
  - `invite_token` string, nullable
  - `niche` string[]
  - `country` string, nullable
  - `language` string[]
  - `brand_kit` CreatorPartnershipBrandKitDataDTO, required — Creator-declared brand-kit values plus optional native-app proof. The landing page normally sends screenshots for private analytics. Integrations such as a Google Forms Apps Script may already provide structured values, so those fields are accepted too; the service fills missing data directly and sends genuine conflicts through GPT-4o-mini.
    - `engagement_rate` number, nullable
    - `audience_demographic` object, nullable
    - `profile_visits` integer, nullable
    - `last_30_days_post_performance` object, nullable
    - `followers` integer, nullable
    - `published_rates` object[], nullable
    - `engagement_rate_screenshot` ScreenshotUploadDTO — One creator-submitted proof file, sent either inline or by link. content_base64 is what the landing-page form sends: it holds the file in the browser, so it can post the bytes straight into the request. source_url is for the intake paths that only ever have a link — a Google Form's Apply Script hands over a Drive file, and re-downloading it in the browser just to re-upload it would be silly. Either way the file ends up on our own bucket, so nothing downstream depends on the original link staying reachable.
      - `filename` string, nullable
      - `content_base64` string, nullable
      - `source_url` string, nullable
      - `content_type` string, nullable
    - `audience_demographic_screenshot` ScreenshotUploadDTO — One creator-submitted proof file, sent either inline or by link. content_base64 is what the landing-page form sends: it holds the file in the browser, so it can post the bytes straight into the request. source_url is for the intake paths that only ever have a link — a Google Form's Apply Script hands over a Drive file, and re-downloading it in the browser just to re-upload it would be silly. Either way the file ends up on our own bucket, so nothing downstream depends on the original link staying reachable.
      - `filename` string, nullable
      - `content_base64` string, nullable
      - `source_url` string, nullable
      - `content_type` string, nullable
    - `profile_visits_screenshot` ScreenshotUploadDTO — One creator-submitted proof file, sent either inline or by link. content_base64 is what the landing-page form sends: it holds the file in the browser, so it can post the bytes straight into the request. source_url is for the intake paths that only ever have a link — a Google Form's Apply Script hands over a Drive file, and re-downloading it in the browser just to re-upload it would be silly. Either way the file ends up on our own bucket, so nothing downstream depends on the original link staying reachable.
      - `filename` string, nullable
      - `content_base64` string, nullable
      - `source_url` string, nullable
      - `content_type` string, nullable
    - `last_30_days_post_performance_screenshot` ScreenshotUploadDTO — One creator-submitted proof file, sent either inline or by link. content_base64 is what the landing-page form sends: it holds the file in the browser, so it can post the bytes straight into the request. source_url is for the intake paths that only ever have a link — a Google Form's Apply Script hands over a Drive file, and re-downloading it in the browser just to re-upload it would be silly. Either way the file ends up on our own bucket, so nothing downstream depends on the original link staying reachable.
      - `filename` string, nullable
      - `content_base64` string, nullable
      - `source_url` string, nullable
      - `content_type` string, nullable
    - `followers_screenshot` ScreenshotUploadDTO — One creator-submitted proof file, sent either inline or by link. content_base64 is what the landing-page form sends: it holds the file in the browser, so it can post the bytes straight into the request. source_url is for the intake paths that only ever have a link — a Google Form's Apply Script hands over a Drive file, and re-downloading it in the browser just to re-upload it would be silly. Either way the file ends up on our own bucket, so nothing downstream depends on the original link staying reachable.
      - `filename` string, nullable
      - `content_base64` string, nullable
      - `source_url` string, nullable
      - `content_type` string, nullable
    - `brands_worked_with` string[], nullable
    - `published_rate` number, nullable
    - `published_rate_pdf` ScreenshotUploadDTO — One creator-submitted proof file, sent either inline or by link. content_base64 is what the landing-page form sends: it holds the file in the browser, so it can post the bytes straight into the request. source_url is for the intake paths that only ever have a link — a Google Form's Apply Script hands over a Drive file, and re-downloading it in the browser just to re-upload it would be silly. Either way the file ends up on our own bucket, so nothing downstream depends on the original link staying reachable.
      - `filename` string, nullable
      - `content_base64` string, nullable
      - `source_url` string, nullable
      - `content_type` string, nullable
    - `best_performing_reel_url` string, nullable
    - `brand_names` string[], nullable

## Response `202`

Successful Response

- CreatorPartnershipJobStartedResponseDTO — Accepted creator-partnership upgrade; processing continues in a Remy job.
  - `job_id` string, required
  - `status` string, required
  - `operation` string, required
  - `requested_plan` string, required
  - `status_url` string, required

## Other responses

- `422` — Validation Error

## Changes

> 20 revisions in range; 1 not diffed.

- **2026-09-16** `dda5cf04b73d` — 1 breaking, 7 info
  - removed the success response with the status `200`
  - added the new optional request property `brand_kit/audience_demographic`
  - added the new optional request property `brand_kit/engagement_rate`
  - added the new optional request property `brand_kit/followers`
  - …4 more
- **2026-09-11** `163530d84bc1` — 1 info
  - endpoint added

[Change history](https://skmtc.dev/brandbooster/apis/fastapi/changes/api/v1/remy/creator-partnership/brand-kit/post.md)

---

[API](https://skmtc.dev/brandbooster/apis/fastapi.md) · [All operations](https://skmtc.dev/brandbooster/apis/fastapi/llms.txt) · [OpenAPI document](https://skmtc.dev/brandbooster/apis/fastapi/revisions/2a70cf5697f4?raw)