An offer is one concrete implementation of a service by a data source. Its id has exactly two segments, source/name:
  • Source: where the data comes from, apify or brightdata. Contractual and public.
  • Name: for a marketplace source, the handle of the actor’s author (harshmaur, apimaestro, compass). For a first-party source, the platform it covers (brightdata/reddit).
The exact upstream identifier (an Apify actor id, a Bright Data dataset id) stays internal. It is an implementation detail of the offer, not part of your contract. Written out in full, a run reads reddit/subreddit.posts @ apify/harshmaur: service on the left, offer on the right.

​
The provider field is optional

Omitting provider is the default and the recommended one. Pin an offer when you are benchmarking it, when you need a specific source for compliance reasons, or when you’d rather have a fast deterministic error than a slower fallback success.

​
How the chain is built

For a given service, the chain is every offer that implements it, ordered by price per record ascending (an offer can be pinned to an explicit rank when there is a reason to prefer it), then filtered by capacity: an offer whose batch cap is smaller than your input count drops out of the chain instead of blocking the call. Concretely, on reddit/subreddit.posts with offers apify/harshmaur (cap 10) and apify/trudax (cap 10), a 5-URL request can use both, while a 50-URL request uses neither and returns a corrective error naming the caps. Where caps differ, say cap 10 and cap 100, a 50-URL request simply skips the small one. You are billed once, against the offer that succeeded. Failed attempts earlier in the chain are logged and never charged.

​
Reading the result

  • served_by: the offer that actually answered. null when the run failed.
  • fallback_from: present only when the chain rolled over. It holds the offer that was tried first.

​
Sources

A source is the vendor behind a family of offers. GET /v1/providers gives the light per-source view: name, description, status, platforms covered, how many services and offers it backs. All the detail (prices, caps, which offer serves what) lives on GET /v1/services.

​
Pricing

Every offer publishes its own price_per_record. Two offers of the same service can differ by a factor of several, which is exactly why the chain is price-ordered, and why pinning an expensive offer is a deliberate act. See credits & pricing for how billing works, and the failover guide for what triggers a rollover.