Apify Creator Data API: What It Returns

Yes, Apify has a documented public REST API. It is a solid one. What it returns is a platform-defined run envelope (run id, status, timestamps, storage ids, usage) plus dataset items whose schema is defined by whoever wrote the Actor you called, not by Apify. That distinction is the whole story when you are evaluating an Apify creator data API path for UGC sourcing.

This walks through the actual request and response model, where it holds up, where it breaks for creator data specifically, how the compute-based billing behaves under retries, and when rolling your own scraper is still the correct decision. Verify every endpoint path and price against Apify's current docs and pricing page before you commit, because both move.

What Apify Actually Is

Apify is cloud infrastructure for running containerized scraping and automation jobs, which it calls Actors, plus the storage, scheduling, proxy and API layer around them. You can publish your own Actor or call one from their public store, written by a third-party developer. The platform guarantees execution, storage and an API over both. It does not guarantee what comes out of any given Actor.

That is the mental model to hold: Apify is a runtime, not a dataset. Compare that to a creator data API, where the vendor owns the schema and the extraction logic and you own only your query. With Apify you own the orchestration, the schema drift, and the choice of which Actor to trust.

A concrete case. An ops lead at a four-person paid social agency wanted a weekly sweep of TikTok creators posting in the pet supplement space. She picked a store Actor, set a scheduled run with a list of hashtags as input, pointed a webhook at an internal endpoint, and wrote the dataset items into Postgres. It worked for two months. Then the Actor's author renamed a nested field, her upsert kept running without errors, and the dashboard quietly stopped showing bio links. Nothing in Apify was broken. The contract she was depending on simply did not exist.

Apify API Endpoints and Response Format

The API is token-authenticated and organized around three nouns: Actors, runs, and storages (datasets, key-value stores, request queues). The normal integration is asynchronous. You start a run with an input payload, you get back a run object, you poll the run or wait on a webhook, then you read items out of the run's default dataset. There is also a synchronous variant that starts a run and returns dataset items in a single call, which is fine for short jobs and a trap for long ones.

The shape looks roughly like this. Treat it as illustrative and confirm the exact paths and parameters in Apify's current API documentation before you write code against it.

POST /v2/acts/{actorId}/runs        -> run object
GET  /v2/actor-runs/{runId}         -> run object, updated status
GET  /v2/datasets/{datasetId}/items -> array of Actor-defined records

An illustrative run response, not a measured one:

{
  "data": {
    "id": "<runId>",
    "actId": "<actorId>",
    "status": "SUCCEEDED",
    "defaultDatasetId": "<datasetId>",
    "startedAt": "<timestamp>",
    "finishedAt": "<timestamp>"
  }
}

That envelope is stable and genuinely useful. Statuses are enumerated, runs are addressable, datasets support offset and limit pagination and multiple output formats, and webhooks fire on run lifecycle events so you are not stuck polling. If you are building a job runner, this is a good API.

The dataset items are the part you cannot plan around. Two Instagram Actors will hand you two different objects for the same profile. One nests engagement under a stats key, another flattens it. One returns the bio as a raw string, another splits links out. Your integration is really an integration with one Actor author's taste. Write a validation layer at the ingestion boundary, fail loudly on a missing required field, and snapshot the raw payload so you can diff shapes after a bad run.

Why Apify Fails for Creator and UGC Data

Scraped profile data answers "who posted this" and almost nothing else you need to staff a UGC campaign. Five specific gaps show up in every build.

Schema instability is the first, covered above. The second is identity. You get handles, and handles change. There is no cross-platform resolution in the box, so joining a TikTok handle to the same person's Instagram account is your problem, usually solved with fragile bio-link matching.

The third gap is commercial state. A scraped profile does not tell you whether the creator shoots UGC for brands, what they charge, whether they will sign a usage rights clause, or whether they are currently booked. A public follower count is not a sourcing signal. If you are modelling budget off scraped audience size, you are guessing. Understanding Usage Rights Terms UGC Ad Contracts: 2026 Guide matters more than any follower field when you are trying to build a defensible budget.

Fourth is maintenance. Store Actors are third-party software. Authors deprecate them, target sites change, and your pipeline inherits that risk without a support contract.

Fifth is compliance. Contact extraction, personal data handling and the target platform's terms are entirely on you. Legal review is part of the build cost, not an afterthought.

Where Apify is the right call: one-off research you will never rerun, platforms with no commercial data vendor behind them, archival collection where you need the raw HTML, and any case where you need custom parsing nobody sells. If your requirement is "crawl these 300 brand sites for an affiliate disclosure footer", Apify is a better answer than any creator API. Be honest about which job you have before you pick a tool.

A worked case: a DTC skincare brand built a shortlist tool on a store Actor. They got handles, bios and recent post captions, which was enough to rank by topical fit. It told them nothing about who would actually accept a brief. The team ended up cold-DMing the list by hand and sourcing most of their roster from a platform where creators were already pitching. If you are thinking through how to Structure Product Seeding Campaigns That Convert to Organic Posts, you will quickly see why scraped handle lists do not substitute for a pool of opted-in creators.

Compute Units Pricing and Hidden Costs

Apify meters compute, not results. The billing unit scales with memory allocated multiplied by runtime, and sits alongside proxy traffic, storage, and whatever price the Actor author sets for their own Actor. Check their live pricing page for current rates and terms, because the figures change and the Actor-level prices vary by author.

The practical consequence is that your bill is a function of how the target site behaves, not how much data you got. A run that gets rate-limited and retries costs more and returns less. Over-provisioning memory because an Actor once ran out of heap doubles your per-minute cost forever. A synchronous call that waits on a long job burns the same compute as the async version plus your own connection time. Blocked requests that return empty pages still cost compute.

A short estimation checklist before you commit:

1. Run the Actor once at the memory setting you plan to use, and record the run's reported usage.
2. Multiply by your real schedule frequency, not your optimistic one.
3. Add a retry factor. Scraping failure rates are not zero and are not stable.
4. Price residential proxy traffic separately if the target blocks datacenter IPs.
5. Add the Actor author's own charge, if any.
6. Add the engineering hours for schema breakage, which is the line item teams always forget.

Credit-metered APIs behave differently because the unit is a unit of work. On the UGC Roster data API, announced 2026-09-05, a search costs 10 credits and a profile read costs 1, with Starter at $49 per month for 25,000 credits, Growth at $199 for 150,000, Scale at $499 for 500,000, and Enterprise custom. There is no free tier. The point is not that one model is cheaper in all cases, it is that you can forecast one from your query volume and the other only from observed runtime.

Platforms Built for Creator Sourcing

There are three categories worth separating. Scraper infrastructure (Apify) gives you a runtime. Influencer discovery platforms give you a UI with an API attached. Creator data APIs give you a typed endpoint and own the extraction themselves.

In the second group, Modash publishes plans starting at $199 per month with a 14-day free trial and no credit card required, and describes a database of 350M+ creators on modash.io (checked 2026-08-22). Confirm current terms on their site before you build against it.

UGC Roster ships a public REST API with a documented surface. The base URL is https://www.ugcroster.com/api/v1, and the www host is required because the bare apex redirects and drops the Authorization header. Keys are issued per brand account, prefixed rsk_, hashed at rest, and passed as a bearer token. Requests are rate limited per brand account and return standard rate-limit headers. Exceeding the limit returns 429 with code RATE_LIMITED.

# Illustrative request shape. See api.ugcroster.com/docs for current parameters.
curl -H "Authorization: Bearer rsk_..." \
  https://www.ugcroster.com/api/v1/creators/search

The endpoint groups available today are /roster and /roster/add, /creators and /creators/search, /briefs, /campaigns, /contracts, /deliverables, /content (plus /content/{id}/refresh), /applications, /commissions, /affiliates/links, /analytics, /messages, /payouts, /shipments, /assets and /assets/folders, /brand, and /webhooks. The /creators/search endpoint requires an active brand plan on the key's account. An MCP server wraps the same surface, so the endpoints are reachable from MCP-capable AI clients if you are building an agent rather than a cron job. Data keys are read-only, covering creator search and creator profiles, and are credit-metered. Brand keys come free with any Roster brand plan, cover the full API surface, and are not metered. No latency or uptime target is published, so do not design around one.

For teams sourcing creators for UGC campaigns, platforms where creators are already opted in and pitching eliminate the outreach problem entirely. The Best Noovid Alternatives for UGC Creators in 2025 breakdown covers several of these platforms from the creator side, which is useful context when evaluating which pools you want access to as a brand.

Common Mistakes When Using Apify for UGC

Treating dataset items as a stable contract. Teams map Actor output straight into their model because the first run looked clean. The fix is a schema validator at ingestion that rejects records missing required fields, plus a stored raw payload so you can diff after a bad run.

Picking an Actor by star rating instead of maintenance history. Popularity reflects past usage, not current upkeep. Check the last update date, the changelog, and whether the author responds to issues before you build a pipeline on it.

Using the synchronous endpoint for long jobs. It is convenient in a Postman tab, then it times out behind a load balancer in production. Start the run async, listen on a webhook, and treat the run id as the thing you store.

Estimating cost from one successful run. That run had no retries and no proxy churn. Budget from a week of real scheduled runs, including the failures, before you sign off on a number.

Scraping follower counts and calling it sourcing. Audience size does not predict who returns a brief or accepts usage terms. Source from a pool where creators are actively pitching, then use scraped data for verification, not discovery. If you need guidance on what creators look for before accepting a deal, UGC Portfolio Examples That Win Brand Deals in 2026 gives you the creator perspective that shapes how briefs should be written.

Skipping the legal review on contact data. Extracting and emailing scraped addresses carries obligations that vary by jurisdiction. Decide your position before launch, not after the first complaint.

Rebuilding deduplication every quarter. Handles change, accounts get recreated, and the same person shows up three times. Pick a stable internal creator id on day one and map external handles to it.

Next Steps

Do this first: open your existing Apify runs and classify each one as either custom extraction nobody sells, or creator discovery. Keep the first group on Apify. It is genuinely the right tool for custom crawls. Move the second group, because you are paying compute to rebuild a dataset someone else maintains with a typed schema.

Then price the move honestly. Count your monthly searches and profile reads, apply the credit cost per call, and compare that to a week of observed compute usage rather than your best run.

The UGC Roster API exposes creator search, briefs, campaigns and payouts behind one key at UGCRoster. Read the endpoint list in the docs before you estimate credits, since brand keys and read-only data keys are metered differently.

FAQ

Is Apify a creator data API or a web scraping platform?

Apify is a web scraping infrastructure platform, not a creator data API. It runs containerized jobs called Actors that you configure to extract data from any website, then stores and serves that data back via REST API. A creator data API owns the schema and extraction logic for you. With Apify, you choose which third-party Actor to trust, manage schema changes yourself, and own the risk when a scraper breaks. If you need verified creator contacts and standardized fields, Apify requires you to pick a reliable Actor maintainer and monitor it continuously.

What data does Apify return when scraping Instagram or TikTok creator profiles?

Whatever the Actor author decided to extract and parse from the platform's public HTML or API response. Apify itself returns a run envelope (run ID, status, timestamps, dataset storage reference) plus the dataset items whose schema the Actor defines, not Apify. One Actor might return follower count, bio, and profile URL. Another might add engagement metrics or content history. Fields are inconsistent across Actors, and when an author updates their scraper, field names or availability can change without breaking the run status. You get no guarantee of schema stability.

How does Apify pricing work with compute units, and what is the actual cost per creator profile?

Apify charges per compute unit consumed during Actor execution. Cost per profile depends entirely on the Actor's design, the target platform's response time, and how many retries occur when a scrape fails. A fast, efficient Actor might extract a profile in seconds (low cost), while a slow or retry-heavy one could consume multiples more. Apify's pricing page shows compute unit rates, but without running a test job and monitoring its consumption, you cannot predict your per-profile cost. Budget for experimentation before relying on it for recurring sourcing.

Why do brands typically move away from Apify to specialized creator data platforms?

Schema drift, maintenance burden, and hiring workflow misalignment. When an Actor's author stops updating it or a platform changes its layout, your downstream pipelines break silently. You maintain data quality alone. Specialized creator platforms like UGC Roster or JoinBrands own the extraction, normalize the schema, and build hiring workflows (briefs, applications, contracts, payment) into the product. Apify is extraction infrastructure. It is not a creator sourcing tool. Brands start with Apify for cost, then move when data reliability and time-to-hire become critical.

What are the main technical limitations of Apify for UGC creator sourcing?

No verified contact data for outreach. Apify scrapes public profiles, which rarely include working email addresses or reliable DMs. You get username and follower count, not a pitch channel. Platforms like Instagram and TikTok actively prevent scraping or rate-limit it, so retry failures and timeouts are common and expensive. Schema changes and Actor abandonment are frequent. Most critically, Apify has no hiring workflow: you get data, but no way to post a brief, collect applications, or manage contracts inside the platform. You need to export and integrate downstream.

Which creator data platforms are built specifically for brand hiring workflows instead of general web scraping?

UGC Roster, JoinBrands, Insense, and GRIN are creator marketplaces with integrated sourcing, applications, contracts, and payment. They host verified creators who opt in to be discovered, so you get working contacts and explicit consent. Trend and minisocial focus on managed UGC production (you post a brief, they match and shoot content). Apify is none of these. It is a data extraction layer. If your workflow is "find creators, send DMs, negotiate rates, collect deliverables, pay them," a creator platform owns that end-to-end. Apify gets you data only.

Does Apify provide verified creator contacts or email addresses for outreach?

No. Apify scrapes whatever is publicly visible on creator profiles. Most Instagram and TikTok profiles do not display working email addresses. You might find a contact link in a bio, but Apify will extract it as a URL string, not validate it. Verified creator platforms like UGC Roster maintain creator accounts with confirmed contact details and direct messaging inside their own app. If you are sourcing for paid work, unverified scraped emails lead to bounces and ghosting. Start with a creator platform if contact quality matters.

How does Apify compare to platforms that focus exclusively on creator and influencer data?

Apify is a generic scraping runtime; creator platforms are verticalized marketplaces. Apify charges per compute unit and requires you to choose and monitor an Actor. Creator platforms like Modash normalize creator profiles, verified contacts, and discovery filters into a searchable dashboard. Apify returns raw extracted data; creator platforms return hiring-ready leads. For one-off analysis or research, Apify is cheaper and faster. For ongoing UGC hiring, a creator platform eliminates schema management and unifies sourcing with hiring workflow. If you are actively looking for work as a creator rather than sourcing talent as a brand, Where to Find UGC Jobs That Actually Pay Well in 2026 covers the platform side of that equation.