What an affiliate link API actually does

An affiliate link API does four things: it mints a tracked destination URL per creator per campaign, it records click events on redirect, it accepts conversion data from your store, and it writes a commission record you can pay against. Everything else (dashboards, leaderboards, payout runs) is a read on top of those four primitives.

UGC Roster's REST API exposes /affiliates/links, /commissions, /campaigns and /payouts on the same key, with base URL https://www.ugcroster.com/api/v1 and docs at api.ugcroster.com/docs. This page covers how the pieces fit, where attribution quietly fails, and when writing your own redirect service is the correct call instead.

Strip the marketing away and an affiliate system is four components.

The link record ties a creator identity to a campaign and a destination. It holds a short code, the target URL, and whatever metadata you need for reporting. It is created once and lives for the life of the campaign.

The redirect handler is the hot path. Somebody taps the link, the handler resolves the code, writes a click event, sets a first-party identifier, and issues a 302 to the destination with a click identifier appended as a query parameter. This path cannot call a remote API synchronously if you want it to survive a viral post.

The click store is append-only. One row per click, with timestamp, code, user agent, IP-derived country, and referrer where you get one.

The conversion ingest takes an order event from your commerce platform, matches it to a click or a code, applies the commission rule, and writes a commission record.

A worked example. A DTC electrolyte brand runs a creator campaign on Shopify. Ops creates one link per creator at campaign kickoff through the API, pushes the short URLs into the creator briefs, and subscribes to the store's orders/create webhook. When an order lands carrying the click identifier in a cart attribute, the ingest job matches it to a creator and writes a commission at the rate in the contract. Finance pays the batch at month end from the commission ledger, not from a spreadsheet.

The part teams underestimate is the rule layer. Flat fee plus commission is now standard in UGC deals, so your commission record needs to coexist with a contract that already pays a base rate. If you are still setting those base rates by feel, the UGC rate calculator gives you a defensible starting number before you layer a percentage on top.

If you want to see how AI tooling can automate the sourcing side before you even get to link creation, Build an AI Agent That Sources and Briefs UGC Creators walks through a practical setup.

Auth, keys, and what each key type unlocks

UGC Roster uses bearer auth. Keys are issued per brand account, prefixed rsk_, hashed at rest, and managed by the account holder.

curl "https://www.ugcroster.com/api/v1/campaigns" \
  -H "Authorization: Bearer $RSK_KEY"

One detail that will cost you an afternoon: the bare apex host redirects and drops the Authorization header. Use www.ugcroster.com in every base URL, including the one buried in your test fixtures.

There are two key types and they are not interchangeable.

Brand keys come free with any Roster brand plan and cover the full API surface, including /affiliates/links, /commissions, /payouts, /contracts and /webhooks. They are not credit metered. If you are building affiliate infrastructure, this is the key you need, because writes are not available on the other type.

Data keys are read-only and cover creator search plus creator profiles. They are credit metered and self-serve at api.ugcroster.com: Starter is $49/month for 25,000 credits, Growth is $199/month for 150,000, Scale is $499/month for 500,000, and Enterprise is custom. A search costs 10 credits and a profile read costs

1. There is no free tier. Note that /creators/search requires an active brand plan on the key's account.

Practical key hygiene, in the order I would set it up: separate keys per environment, keys in your secrets manager rather than your CI config, and a rotation you have actually rehearsed once before you need it. An MCP server wraps the same API surface, which matters if you are driving campaign steps from an AI client rather than a cron job. For a step-by-step walkthrough of that setup, see How to Set Up the UGC Roster MCP Server with Claude.

On the competitive picture, be careful what you assume. Superfiliate markets influencer, affiliate and referral commerce for Shopify, Meta and TikTok Shop, and as of a check on 2026-08-22 its site is demo-only with no public pricing. GRIN states on its homepage (same check date) that it charges no commissions on simple affiliate programs and that paid plans begin at $200/month. For a detailed breakdown of how those platforms compare, Aspire vs Grin: Real Differences in Features and Pricing covers the practical tradeoffs. Neither homepage is a developer docs page, so if API access is a hard requirement, ask each vendor for the docs URL and the auth model in writing before you scope anything.

Creating affiliate links programmatically

Link creation is a POST. The request body schema, including field names, lives in the docs. Do not copy field names from blog posts, including this one.

Illustrative only. Body schema comes from api.ugcroster.com/docs.
curl -X POST "https://www.ugcroster.com/api/v1/affiliates/links" \
  -H "Authorization: Bearer $RSK_KEY" \
  -H "Content-Type: application/json" \
  -d @link.json

The shape of a sane creation job:

1. Pull the campaign from /campaigns and the participating creators from /roster.
2. Check your local mapping table for an existing link keyed on creator plus campaign. If a row exists, skip.
3. POST the link, store the returned identifier and URL in your mapping table in the same transaction that marks the creator as provisioned.
4. Write the short URL into the brief or the contract, not into a separate sheet.
5. Log every failure with the creator identifier so a rerun is a filter, not a full replay.

Step 2 is the whole game. The API will happily create a second link if you POST twice, so your idempotency has to live in your own store unless the docs give you an idempotency mechanism. Retries after a timeout are the most common source of duplicate codes, because the write succeeded and the response never arrived.

One agency pattern worth stealing: generate codes from a slug of the creator handle plus a two-character campaign suffix, so support can read a code out loud on a call. Random codes are safer against enumeration but make manual reconciliation miserable.

Tie the link to the deliverable, not just to the person. A creator posting three videos in one campaign should carry one link, with the post-level split coming from your click data (referrer, landing timestamp, or a source parameter you append per post). Minting a fresh link per post fragments your commission ledger for no analytical gain. If your briefs do not yet specify where the link goes and in what format, the UGC brief generator is a faster fix than another Slack thread.

Click attribution and commission reconciliation

Attribution breaks in predictable places. Plan for these three.

Cookie lifetime. If you set your attribution cookie with document.cookie in the browser, WebKit caps it at seven days. Apple documented this in Intelligent Tracking Prevention 2.1, published 21 February 2019. A 30-day affiliate window enforced with a script-written cookie is a 7-day window on Safari. Set the cookie server-side in the redirect response instead.

Click identifier passthrough. Append a click id on the redirect and capture it into a cart attribute or order note at checkout. That gives you a server-side join key that does not depend on cookies surviving an in-app browser handoff. In-app browsers on TikTok and Instagram can strip referrers, so treat referrer-based attribution as a fallback and never as your primary signal.

Code fallback. Issue a discount code alongside every affiliate link. When the click chain breaks, the code still identifies the creator at checkout. Link-in-bio traffic is the usual culprit: the order arrives carrying the discount code and no click id. Without the code fallback those orders get marked organic and nobody gets paid.

Reconciliation is a daily job, not a launch task:

1. Pull yesterday's commission records from /commissions with your date filter.
2. Pull yesterday's orders from the commerce platform.
3. Join on order identifier and diff. Flag orders with a click id but no commission, and commissions with no matching order.
4. Hold refunded and cancelled orders in a pending state until your return window closes, then reverse.
5. Release approved commissions into a payout batch through /payouts.

Shopify's webhook documentation states that webhooks can be delivered more than once and recommends deduplicating on the X-Shopify-Webhook-Id header (shopify.dev webhooks docs, checked September 2026). Take that seriously. Duplicate order webhooks are the single most common cause of double-paid commissions.

When you model the commission budget for a campaign, run it against your blended CAC before you set the rate, not after. The UGC budget calculator is a quick sanity check on whether flat plus commission still works at volume.

What breaks at scale

Rate limits. Requests are rate limited per brand account and return standard rate-limit headers. Exceeding the limit returns 429 with code RATE_LIMITED. Read the headers and back off proactively rather than waiting for the

429.

Illustrative retry shape, not measured timings.
for attempt in range(5):
    r = session.post(url, json=payload, headers=headers)
    if r.status_code != 429:
        break
    wait = float(r.headers.get("Retry-After", 2  attempt))
    time.sleep(wait + random.uniform(0, 0.5))

Thundering herd at kickoff. A 200-creator drop where every link is created at 9:00am in a tight loop is the fastest way to meet the limiter. Queue link creation with a fixed concurrency cap and start it the night before. Provisioning is not time sensitive. The campaign start is.

Redirect path coupling. Never call a remote API inside the redirect. Cache link records locally, resolve from cache, and treat the API as the source of truth you sync on a schedule. A cache miss should fail open to the campaign landing page, not to a

500.

Webhook duplicates and out-of-order delivery. Persist the event identifier, make the handler idempotent, and store the raw payload before you process it. Replaying from stored payloads is how you recover from a bad deploy without asking the vendor to resend.

Bot clicks. Link preview crawlers and datacenter traffic inflate click counts and wreck conversion rates. Filter known crawler user agents at write time and keep the raw rows in a separate table so you can revisit the filter.

Pagination drift. Long-running paginated pulls over a table that is actively being written can skip or repeat rows. Page by a stable sort key and a time bound, not by offset.

Common mistakes

Treating UTM parameters as attribution. UTMs are analytics annotations. They get stripped, rewritten by platforms, and edited by creators pasting links into captions. Teams use them because they are already in the marketing stack. Use a real affiliate code plus a server-side click id, and keep UTMs for reporting only.

Minting a new link per post. It feels tidier and it destroys your ledger. One creator ends up spread across six commission streams, and contract reconciliation turns manual. Issue one link per creator per campaign and differentiate posts with an appended source parameter.

Client-side cookies for a 30-day window. People copy a snippet from a 2017 tutorial and never check Safari. Per WebKit's ITP 2.1 announcement (21 February 2019), script-written cookies are capped at seven days. Set attribution cookies in the redirect response from your server.

No idempotency on link creation. A timeout triggers a retry, the retry succeeds, and now two codes point at one creator. The clicks split across them. Keep a local mapping table keyed on creator plus campaign and check it before every write.

Reconciling against the dashboard instead of the store. Any single system will agree with itself. Diff commission records against your commerce platform's order export daily, and alert on the delta rather than eyeballing it at month end.

Letting creators re-shorten the link. Creators run affiliate URLs through their own shortener for a cleaner caption, and query parameters get dropped. It happens because nobody told them not to. Hand them a branded short link that already looks clean, say plainly in the contract that the URL must be used unmodified, and monitor for traffic arriving without a click id.

Hardcoding the apex domain. ugcroster.com/api/v1 redirects and the Authorization header is dropped on the way, so you get a 401 that looks like a bad key. Use www.ugcroster.com everywhere, including in whatever fixture file you forgot about.

Next steps

Do this first: build the reconciliation diff before you build anything else. Pull commissions, pull orders, join, and alert on mismatches. Every other part of an affiliate integration can be fixed after launch. Attribution you never checked cannot be reconstructed, because the clicks are gone.

After that, decide honestly whether you need a vendor at all. If you run one store, one domain, and a small creator list, a Cloudflare Worker redirect, a Postgres table, and a Shopify order webhook will do the job in a weekend and cost nothing. Buy when you need multi-brand keys, contract and payout records attached to the same creator identity, or an audit trail somebody else maintains.

If buying is where you land, look at what the UGC Roster API covers against that list. Start in the API docs and confirm the request schema for /affiliates/links against the live reference before you write the client.

Then tighten the commercial side: set base rates with the UGC rate calculator, model the commission layer with the UGC budget calculator, and ship the link placement requirements inside the brief using the UGC brief generator. More engineering-side walkthroughs live in the creator data API guides.

FAQ

What is click attribution in an affiliate API context?

Click attribution is the chain that connects a tap on a creator's link to a payable commission record. Three things have to line up: a click event written at redirect time, an identifier that survives the trip into the checkout, and an order event that carries that identifier back to you. Break any link and the order lands as "direct". The edge case that bites teams is the attribution window. If a viewer taps a TikTok bio link on Tuesday and buys on Sunday, your rule decides whether that creator gets paid. Set the window explicitly before launch, not after your first payout dispute.

How do you create affiliate links for 50 creators in one API run?

Do it in five steps. First, create the campaign with /campaigns so every link has a parent to report against. Second, pull the creator list from /roster rather than a spreadsheet, so identities match what your commission records will reference. Third, loop /affiliates/links, one call per creator, and persist the returned code alongside your own creator ID. Fourth, register your conversion endpoint through /webhooks. Fifth, reconcile against /commissions at the end of the run and re-drive anything missing. Add backoff on 429 RATE_LIMITED responses, because a 50-item loop fired with no delay is exactly what trips per-account rate limits.

Is this a viable Apify alternative for creator and UGC data?

Partly, and it depends on what you are actually pulling. Apify is a general scraping platform where you run actors against public pages, including social sites. UGC Roster does not scrape anything. /creators/search and the profile reads return first-party records from the directory, people who signed up to be hired. If you run an actor nightly to collect hashtag posts for trend research, keep it. If you run one to assemble a shortlist of UGC creators for a Q4 ad test, the directory is the shorter path, and the same key then covers /briefs, /contracts and /payouts for whoever you book.

How does it compare to Bright Data for creator and UGC data?

They solve different problems, so this is rarely a swap. Bright Data sells web data infrastructure: proxies and collectors for pulling public pages at volume. UGC Roster sells read access to a hiring directory plus the workflow endpoints around it. Concretely: if you need a market map of a million public profiles, that is a Bright Data job and nothing here replaces it. If you need 40 creators who will film a skincare ad in two weeks, search the directory. Data keys are read-only and credit-metered, starting at $49 a month for 25,000 credits, with a search costing 10 credits and a profile read

1.

Is there a ScrapeCreators alternative for creator and UGC data?

Yes for sourcing, no for arbitrary platform stats. If your app needs per-video metrics on any public TikTok handle, keep a social-data vendor in the stack. If your app needs to find hireable creators and read their profiles, the UGC Roster data key covers that, and the published credit costs make a month of usage easy to model before you commit. There is no free tier, so budget the first month rather than prototyping for nothing.

What is a good Phyllo alternative for creator and UGC data?

Ask what kind of data you need first, because Phyllo sits in the creator-authorized category. That model has each creator connect their accounts to your app, which is how you get private numbers like watch time or audience breakdowns. UGC Roster is not that. You get directory search and profile reads for creators already on the platform, plus the endpoints to brief, contract and pay them. If you are building an analytics dashboard that reports a creator's own performance back to them, authorized data is correct. If you are building sourcing for an ad team, start with the developer docs instead.

How does it compare to Modash for creator and UGC data?

Modash indexes a very large pool of public creator profiles for discovery and vetting. UGC Roster indexes a smaller, curated pool of UGC creators, all of whom joined the platform to get hired. Different bet. Modash publishes plans starting at $199 a month with a 14-day free trial and no credit card required (verified on modash.io, 2026-08-22). UGC Roster data keys start at $49 a month for 25,000 credits, with no free tier. If your workflow ends at a shortlist, either works. If it continues into contracts, deliverables and payouts, that lives on the same key here.

Is there an EnsembleData alternative for creator and UGC data?

Not if you need raw platform endpoints. EnsembleData-style vendors exist to give you video-level and account-level data straight off the social platforms, and the UGC Roster API does not expose that. Where it does overlap is the sourcing half of your product: creator search and profile reads on a read-only, credit-metered key. One practical note if you are migrating any integration here. Rate limits apply per brand account and exceeding them returns a 429 with code RATE_LIMITED, so your worker pool needs backoff logic before you point a nightly batch job at it.

Can it replace a RapidAPI listing for creator and UGC data?

Yes, in the sense that you can integrate direct and skip the marketplace layer entirely. You get a key from your brand account, prefixed rsk_, and send it as Authorization: Bearer. One gotcha worth knowing before you debug it for an hour: the base URL must be https://www.ugcroster.com/api/v1, because the bare apex host redirects and the Authorization header gets dropped on the way. If your HTTP client follows redirects silently, you will see 401s that look like a bad key. There is also an MCP server wrapping the same surface, which is handy if you are wiring this into an AI client.

Is it a PhantomBuster alternative for creator and UGC data automation?

No, not for browser automation. PhantomBuster-style tools drive sessions against social platforms to scrape and message. Nothing in this API does that. What the brand key does cover is the workflow layer: /campaigns, /applications, /messages, /deliverables and /webhooks, so an agency ops lead can script campaign setup and status sync instead of clicking through a dashboard. The creator-side automation, meaning verified brand contacts with Gmail-connected pitch sends and follow-ups, is part of the $29 a month creator plan rather than an API endpoint. Worth being clear on that split before you scope a build around it.

Related reading

• UGC ROI Calculator
• UGC Budget Calculator
• UGC Contract Generator
• Creator Business (free course track)
• Landing Brand Deals (free course track)