Brand key required
Applications
Applications are read through their campaign; the write surface is a single PATCH that approves, rejects, or hires. Hiring is the interesting one: it fans out into your roster.
Reading applications
List a campaign’s applicants with GET /v1/campaigns/{id}/applications (filterable by status, paginated), documented on the Campaigns page. The id of each item is what you PATCH here.
Update an application
PATCH/v1/applications/{id}
| Field | Type | Description |
|---|---|---|
| id | string (path) | Application ID from the campaign applications list. |
| status | string | Required. One of: approved, rejected, hired. Any other value returns 422 VALIDATION_ERROR. |
request: hire an applicant
curl -X PATCH "https://api.ugcroster.com/v1/applications/app_001" \
-H "Authorization: Bearer rsk_brand_key" \
-H "Content-Type: application/json" \
-d '{ "status": "hired" }'response 200
{
"data": {
"id": "app_001",
"status": "hired",
"updated_at": "2026-06-13T15:00:00Z"
}
}What “hired” does
Setting status: "hired" does more than flip a flag:
| Side effect | Type | Description |
|---|---|---|
| roster entry | created | A hire record is created for the applicant (deduped by email: hiring the same creator twice is a no-op), carrying the campaign link and its compensation. |
| deliverables | seeded | Deliverable placeholders with status "requested" are auto-created for the hire (best-effort; never blocks the hire). |
| agency deals | advanced | If the creator is agency-managed, the deal is advanced and the creator notified. |
approved and rejected only update the application status. Use them for shortlisting-style flows before committing to a hire.
Errors
| Status | Type | Description |
|---|---|---|
| 404 NOT_FOUND | application / campaign | Unknown application ID, or its campaign no longer exists. |
| 403 FORBIDDEN | ownership | The application belongs to a campaign owned by a different brand. |
| 422 VALIDATION_ERROR | body | Missing or invalid status value. |