Fiverr Scraper

Discover Fiverr gig URLs and seller profile URLs from Fiverr's own public sitemaps, and fetch full gig detail records (title, description, category path, pricing packages, rating breakdown, seller card, images, FAQ) — no login, no cookies, no API key, no paid proxy.

Data Source / Scope

The escalation ladder actually walked, with evidence:

1. Direct fetch to Fiverr's search/category/homepage routes -> HTTP 403 (PerimeterX behind Cloudflare, response header fvrr-bl-route-id: px). Confirmed with both plain httpx and curl_cffi chrome131 TLS impersonation. No live-search mode is offered — that route cannot be reached reliably from datacenter infrastructure. Re-verified 2026-07-25: https://www.fiverr.com/categories/graphics-design (top-level category browse), https://www.fiverr.com/categories/graphics-design/creative-logo-design (sub-category browse), and https://www.fiverr.com/gigs/<tag-slug> (tag-search results, e.g. /gigs/logo-design) all also returned

   HTTP 403
   on first request — category/tag browse pages sit behind the same PerimeterX challenge as search, so no byCategory/byTag browse mode is offered either.
2. https://www.fiverr.com/robots.txt -> HTTP 200, publicly accessible, lists Fiverr's own gig/user/category/tag XML sitemaps. Not behind the PerimeterX challenge.
3. https://www.fiverr.com/sitemap_gigs.xml.gz -> sitemap index -> 7 gzip shard files, each listing ~40,000 real, live gig URLs (refreshed daily) plus a preview image per gig. Confirmed 100% reliable from Apify cloud (verified run: shard fetch + parse of 43,592 gig URLs completed in ~2s, zero errors). This is the actor's primary, default mode (discoverGigs). 3b. https://www.fiverr.com/sitemap_users.xml.gz -> sitemap index -> 6 gzip shard files, each listing ~50,000 real seller profile URLs (refreshed daily), each with a profile-photo image and Fiverr's internal numeric user_id. Same sitemap-host path as (3), same zero-cost Tier-1 reliability (re-verified 2026-07-25: HTTP 200, 50,000 parsed entries per shard, zero errors). Exposed as the new discoverSellers mode. 3c. https://www.fiverr.com/sitemap_categories.xml.gz -> a single flat gzip file (no shards), 957 real category/sub-category/nested-sub-category URLs (re-verified 2026-07-26: HTTP 200, same zero-anti-bot sitemap-host path as (3)/(3b)): 12 top-level categories (each carrying a numeric category_id in its android-app:// alternate link), 299 sub-categories (each carrying a numeric sub_category_id), and 645 nested sub-categories (slug-only at that depth — no id embedded in this sitemap, matching the nestedSubCategorySlug a gig's own hydration blob exposes). This is a listing-only mode exactly like discoverGigs/discoverSellers above — it never fetches the category browse pages themselves (those remain blocked, see step 1 and "Rejected candidates"), it only parses the sitemap's own URL + numeric-id metadata. Exposed as the new discoverCategories mode, giving full taxonomy coverage (with real internal IDs) beyond the 12 hardcoded top-level slugs the category filter previously offered. 3d. https://www.fiverr.com/sitemap_tags.xml.gz -> sitemap index -> 2 gzip shard files, each listing ~50,000 real Fiverr search-tag slugs (https://www.fiverr.com/gigs/<tag-slug>), refreshed daily (re-verified 2026-07-26: HTTP 200, same zero-anti-bot sitemap-host path as (3)/(3b)/(3c), 50,000/50,000 URLs in shard 1 matched the tag-URL pattern). Same listing-only contract as the modes above — the tag search pages themselves stay blocked (see step 1), only the sitemap's own slug listing is parsed. Exposed as the new discoverTags mode, giving a browsable/keyword-filterable index into Fiverr's own curated search-tag vocabulary that feeds the searchKeyword filter on the other modes.
4. Individual gig detail pages (https://www.fiverr.com/<username>/<gig-slug>) embed real schema.org JSON-LD (Product, BreadcrumbList, FAQPage) plus a React-hydration JSON blob (#perseus-initial-props) with package/pricing-tier, category-taxonomy, seller-card, and rating-breakdown detail (undocumented shape, best-effort only — see src/helpers.py module docstring). These pages are blocked categorically — re-verified 2026-07-25 with a fresh 20-URL sample spanning 8 categories (logo design, video editing, voiceover, sound design, virtual assistant, certification consulting, mixing/mastering), fetched both from this project's research machine (plain HTTP, no proxy) and previously from live Apify cloud runs (run ID V2mMXnxnbgHz0rRbM, 20/20 attempts 403, both direct and via 12+ freshly-rotated Apify AUTO-group proxy sessions). All 20 URLs in the fresh sample returned HTTP 403 immediately, with no signal that category, URL depth, or seller tier predicts success — the block is uniform. Seller profile pages (https://www.fiverr.com/<username>) were also tested fresh against the same 20-URL sample's usernames and are equally blocked — all 20/20 returned HTTP 403 immediately (see "Rejected candidates" below); this rules out a sellerProfile detail-fetch mode. A Google-Translate mirror fetch (*.translate.goog) was also tried per the anti-bot decision tree's "third-party mirror" escalation step and returned the same PerimeterX challenge body relayed through Google's fetch, so it does not bypass the block either. This points to a hard block of hosting/cloud/automated-tool traffic (both Apify's own egress and its AUTO datacenter proxy pool, and this project's own research connection) rather than a simple per-IP rate limit. Per this project's zero-cost policy, residential proxies are not an option (they bill per-GB against the free-plan credit), so this is the reliability ceiling for gig-detail fetching from Apify cloud.
5. To audit the full field surface of a successfully-fetched gig page despite the live block, 3 real Fiverr gig pages (different categories: Music & Audio/Mastering, Business/Virtual-Assistant, Music & Audio/Voice-Over) were pulled from web.archive.org's historical snapshots (2024-07 to 2024-10 captures) and their JSON-LD + perseus-initial-props blobs audited byte-for-byte. This confirmed: (a) the JSON-LD Product/ BreadcrumbList/FAQPage shape already implemented is complete — no further JSON-LD fields exist; (b) the perseus-initial-props blob's general section additionally carries categoryId/categorySlug/ subCategoryId/subCategorySlug/nestedSubCategoryId/ nestedSubCategorySlug/isPro/gigStatus (previously only gigId was extracted); (c) a seller + overview.seller section carries sellerLevel, isVerified, completedOrdersCount, displayName, languages, countryCode, and profilePhoto — consistently present across all 3 samples; (d) a reviews section carries a real 1-5 star breakdown (count per star) and star_summary (communication/recommend/ service sub-ratings) — also consistently present; (e) a real bug: the package duration field is in hours, not days as the previous extraction assumed — confirmed because each sample's adjacent SEO deliveryTime string (e.g. "1 day"/"2 days") exactly matches duration / 24 (24h -> "1 day", 48h -> "2 days") across all 3 samples in 3 different categories. This has been fixed (see extract_packages in src/helpers.py) and is no longer mislabeling e.g. a 1-day mastering package as a "24 day" one.

Practical consequence: discoverGigs and discoverSellers (sitemap-only, no per-gig/per-seller fetch) are fully reliable and zero-cost. discoverAndFetchDetails and gigDetails still attempt the fetch (direct-first, AUTO-proxy escalation on 403, circuit breaker after sustained failure) in case Fiverr's PerimeterX IP-reputation list changes over time, but customers should expect these two modes to frequently return 0 detail records when run from Apify cloud — this is disclosed here rather than silently shipping a broken default. The parsing logic itself (JSON-LD + embedded state -> full record, including the expanded category/seller/rating fields above) is implemented, unit-tested against realistic fixtures modeled on the real captured Fiverr gig pages, and verified end-to-end whenever a page is actually reachable.

Rejected candidates (investigated, not added):

• sellerProfile detail-fetch mode — rejected. Tested a fresh sample of 20 seller profile URLs (https://www.fiverr.com/<username>, one per sampled gig, spanning 8 categories): 20/20 returned HTTP 403 immediately, identical to the gig-detail-page block. Seller profile pages sit behind the same PerimeterX challenge as gig pages, not a separate/lighter one — there is no reliability gap to exploit here.
• byCategory / byTag browse-and-fetch mode — rejected. The category browse pages (/categories/<slug>[/<slug>][/<slug>]) and tag search-result pages (/gigs/<tag-slug>, from sitemap_tags.xml.gz's 2 shards / 50,000 tag slugs each) are behind the same PerimeterX challenge as /search — confirmed HTTP 403 on direct fetch for 3 category-depth samples and 2 tag samples, re-verified 2026-07-26. However, sitemap_categories.xml.gz itself (the taxonomy listing, not the browse pages it points to) is reliably listable exactly like the gig/user sitemaps — this is now exposed as the discoverCategories mode (see step 3c above), and sitemap_tags.xml.gz (the tag-slug listing) is likewise exposed as the discoverTags mode (see below) — a prior pass rejected discoverTags reasoning it added "no new information beyond what a user could already type into searchKeyword", but that undersells it the same way a discoverCategories-less design would undersell category discovery: a caller can't type a real, high-traffic Fiverr search-tag slug they don't already know exists. discoverTags turns the ~100,000-slug tag sitemap into a browsable/keyword-filterable list (with a human-readable tagName) that feeds directly into the searchKeyword filter on the other modes — re-verified live 2026-07-26: 50,000/50,000 URLs in shard 1 matched the /gigs/<slug> tag pattern, zero anti-bot risk (sitemap host only, same as gigs/users/categories).
• sitemap_logomaker_tags.xml.gz — re-inspected 2026-07-26 (previously marked "out of scope" for not being gig/seller data — that undersold it the same way discoverTags was initially undersold): a flat 1,033-entry <urlset> listing Fiverr's own curated Logo Maker inspiration taxonomy — ~1,014 real /logo-maker/ideas/<taxonomy>/<slug> entries across 6 taxonomies (tag 730, industry 238, monograms 26, brand-values 9, style 6, symbol-type 5), each with a real example-logo image + caption. Now exposed as the discoverLogoMakerIdeas mode. The idea pages themselves (/logo-maker/ideas/tag/<slug>) are behind the same PerimeterX challenge as every other non-sitemap page (confirmed HTTP 403 live, 2026-07-26) — listing-only, same pattern as discoverTags.

Out of scope, explicitly: live keyword search against Fiverr's own search endpoint, category/tag browse pages (see "Rejected candidates"), seller profile detail data beyond what the sitemap lists (username, photo, numeric ID — see "Rejected candidates" for why detail-page seller stats aren't independently fetchable), buyer-only data (order history, messages), and anything requiring a logged-in session.

What this actor does

• 7 modes:
  • discoverGigs (default, reliable) — lists gig URLs from the sitemap only (fast, no per-gig fetch, zero anti-bot risk).
  • discoverSellers (reliable) — lists seller/freelancer profile URLs from Fiverr's own seller sitemap (fast, no per-seller fetch, zero anti-bot risk).
  • discoverCategories (reliable) — lists Fiverr's full category / sub-category / nested-sub-category taxonomy (~950 entries, with real internal numeric IDs for the top 2 levels) from Fiverr's own category sitemap (fast, no per-page fetch, zero anti-bot risk).
  • discoverTags (reliable) — lists Fiverr's own curated search-tag vocabulary (~100,000 real slugs, 2 sitemap shards) from Fiverr's own tag sitemap (fast, no per-page fetch, zero anti-bot risk) — use it to find real keywords for the searchKeyword filter on the other modes.
  • discoverLogoMakerIdeas (reliable) — lists Fiverr's Logo Maker inspiration taxonomy (~1,000 entries: tag / industry / style / symbol-type / brand-values logo ideas, each with a real example image) from Fiverr's own Logo Maker ideas sitemap (fast, no per-page fetch, zero anti-bot risk).
  • discoverAndFetchDetails (best-effort) — walks the sitemap and fetches full detail for each discovered gig, up to maxItems.
  • gigDetails (best-effort) — fetches full detail for a list of gig URLs you already have.
• Keyword filter — substring match against the sitemap-derived gig slug, seller username, or tag slug (and, once fetched, the gig title).
• Post-fetch filters — minimum rating, minimum review count, minimum / maximum starting price (USD), top-level category.
• Category path — full breadcrumb (category / sub-category / nested sub-category) with names + URLs, straight from Fiverr's own structured data, plus exact machine-matchable categorySlug/subCategorySlug/ nestedSubCategorySlug/categoryId fields (used by the category filter).
• Seller card — best-effort seller level, verification status, completed order count, display name, spoken languages, country, and profile photo.
• Rating breakdown — best-effort per-star review counts (1★–5★) plus communication/recommend/service sub-ratings.
• Package breakdown — best-effort per-tier pricing (title, price, delivery days, revisions) when Fiverr discloses it on the page; omitted (never fabricated) when it isn't parseable.
• Empty fields are always omitted — no nulls, no sentinel values.

Output — discovered gig URL (recordType: "gigUrl")

Field	Description
gigUrl	Canonical gig page URL
gigId	Fiverr's internal numeric gig ID, parsed straight from the sitemap's android-app:// alternate link (always present — no detail fetch required)
sellerUsername	Fiverr username, parsed from the URL
sellerProfileUrl	https://www.fiverr.com/<username>
gigSlug	URL slug
imageUrl	First preview image from the sitemap
imageUrls[]	Full image gallery from the sitemap (often more than one)
imageCaption	Caption for the first preview image
previewVideo	{thumbnailUrl, title, description, playerUrl, category} — present for gigs with a video preview (~48% of gigs); playerUrl/thumbnailUrl are directly fetchable, no auth
hasVideoPreview	true when previewVideo is present
sourceSitemapShard	Which of the 7 gig-sitemap shard files this came from
recordType, scrapedAt

Output — discovered seller profile (recordType: "sellerProfile")

Field	Description
sellerUsername	Fiverr username
sellerProfileUrl	https://www.fiverr.com/<username>
sellerId	Fiverr's internal numeric seller/user ID
sellerProfilePhotoUrl	Profile photo from the sitemap
sourceSitemapShard	Which of the 6 seller-sitemap shard files this came from
recordType, scrapedAt

Output — category taxonomy (recordType: "category")

Field	Description
categoryUrl	https://www.fiverr.com/categories/<slug>[/<slug>][/<slug>]
categoryLevel	category / subCategory / nestedSubCategory
name	Human-readable name, title-cased from the URL slug
categorySlug	Top-level category slug (always present)
subCategorySlug	Present at subCategory/nestedSubCategory level
nestedSubCategorySlug	Present at nestedSubCategory level only
categoryId	Fiverr's internal numeric ID — present at category level only
subCategoryId	Fiverr's internal numeric ID — present at subCategory level only
recordType, scrapedAt

Output — search tag (recordType: "tag")

Field	Description
tagSlug	Fiverr's own search-tag slug, e.g. logo-design
tagName	Human-readable name, title-cased from the slug
tagSearchUrl	https://www.fiverr.com/gigs/<tagSlug> (Fiverr's tag search-result page — informational; not fetched by this actor)
sourceSitemapShard	Which of the 2 tag-sitemap shard files this came from
recordType, scrapedAt

Output — Logo Maker idea (recordType: "logoMakerIdea")

Field	Description
ideaSlug	Logo Maker idea slug, e.g. zoo, kids
ideaType	tag / industry / brandValue / style / symbolType
ideaName	Human-readable name, title-cased from the slug
ideaUrl	https://www.fiverr.com/logo-maker/ideas/<taxonomy>/<slug>
imageUrl	Example logo image for this idea
imageCaption	Caption for the example image
recordType, scrapedAt

Output — gig detail (recordType: "gigDetail")

Field	Description
sourceUrl	Canonical gig URL
sellerUsername, sellerProfileUrl, gigSlug	Parsed from the URL
gigId	Fiverr's internal gig ID (when the page's hydration blob is parseable)
gigStatus	e.g. approved
title, description	From Product JSON-LD (description is a short auto-generated SEO summary)
fullDescription	Full seller-written gig description (plain text, stripped of HTML), from the page's own hydration state — materially longer/richer than description
imageUrl	Main gig image
rating	0–5, from Product.aggregateRating
reviewsCount
gigCollectedCount	How many buyers have saved/wishlisted this gig — a popularity signal distinct from reviewsCount
priceMin, priceMax, currency	From Product.offers (AggregateOffer)
packagesCount	Number of pricing packages Fiverr reports
availability	e.g. InStock
category, categoryUrl	Top-level category, from the page breadcrumb
subCategory, subCategoryUrl
nestedSubCategory, nestedSubCategoryUrl	Present when the gig has a 3rd breadcrumb level
categoryPath	Human-readable "Category > SubCategory > NestedSubCategory"
categoryId, subCategoryId, nestedSubCategoryId	Fiverr's internal numeric taxonomy IDs
categorySlug, subCategorySlug, nestedSubCategorySlug	Exact slugs matching sitemap_categories.xml.gz / /categories/<slug> URLs; used by the category input filter
isPro	Whether this is a Fiverr Pro gig
acceptsCustomOrders	Whether the seller accepts buyer-initiated custom offers on this gig
sellerLevel	e.g. LEVEL_TRS (Top Rated Seller), LEVEL_TWO, LEVEL_ONE
sellerIsVerified	Seller identity-verification status
sellerCompletedOrders	Total completed order count
sellerIsHighlyResponsive	Whether Fiverr flags the seller as highly responsive to buyer messages
sellerSkills[]	{name, level} — seller's structured skill tags (e.g. {"name": "Audio mixing", "level": "PRO"})
sellerOverallRating, sellerOverallReviewsCount	Seller-wide rating/review count across all of the seller's gigs — distinct from the per-gig rating/reviewsCount above
sellerDisplayName	Seller's public display name
sellerLanguages[]	Spoken-language codes (e.g. ["EN", "HI"])
sellerCountryCode	ISO country code
sellerProfilePhotoUrl	Seller's profile photo
ratingBreakdown[]	{stars, count} per star value (1–5)
communicationRating, recommendRating, serviceRating	0–5 sub-ratings
packages[]	{tier, title, description, priceUsd, deliveryDays, revisions, extraFastDeliveryPriceUsd, extraFastDeliveryDays} — best-effort, omitted if not parseable. extraFastDelivery* fields appear only when faster delivery is a paid upsell on that tier (omitted when already bundled in)
minDeliveryDays	Fastest package's delivery time, in days
gigExtras[]	{name, description, priceUsd, extraDeliveryDays} — buyer-facing paid add-ons (e.g. "More Stems", "24 Bit Wave"), deduped across package tiers
faq[]	{question, answer} — from the page's JSON-LD FAQPage block, falling back to the hydration state's own FAQ section (identical content) when JSON-LD is absent
gigTags[]	Fiverr's own per-gig search-tag assignment (e.g. ["hip hop", "mixing", "mastering"])
gigGallery[]	{slideType, title, mediaUrl, thumbnailUrl, videoUrl, audioUrl, isWorkSample} — the gig's full media gallery (intro video, audio samples, work images), best-effort
sellerOtherGigIds[]	Other real gig IDs by the same seller
sellerPortfolioProjects[]	{title, imageUrl} — real portfolio project samples the seller has attached to this gig category
sellerPortfolioProjectsCount	Total portfolio project count reported by Fiverr
relatedServiceTypes[]	{serviceTypeName, serviceSlug, startPriceUsd} — Fiverr's own "other service types in this sub-category" cross-sell widget (e.g. a Mixing gig surfaces the Mastering service type with its real starting price)
relatedSubCategoryName	Sub-category name the related service types belong to
recordType, scrapedAt

Input

Field	Type	Default	Description
mode	select	discoverGigs	discoverGigs / discoverSellers / discoverCategories / discoverTags / discoverLogoMakerIdeas / discoverAndFetchDetails / gigDetails
searchKeyword	string	–	Substring filter against gig slug/seller username/category URL/tag slug/logo-idea slug/title
gigUrls	array	[]	Gig URLs (mode=gigDetails)
maxShards	int	1	How many gig-sitemap (max 7), seller-sitemap (max 6), or tag-sitemap (max 2) shard files to scan
categoryLevel	select	–	Taxonomy level filter (mode=discoverCategories): category / subCategory / nestedSubCategory
ideaType	select	–	Logo Maker idea taxonomy filter (mode=discoverLogoMakerIdeas): tag / industry / brandValue / style / symbolType
minRating	number	–	Minimum rating (0–5), applied after fetching detail
minReviews	int	–	Minimum review count
minPriceUsd / maxPriceUsd	number	–	Starting-price range (USD)
category	select	–	Top-level category slug filter (e.g. music-audio) — applied after fetching detail, or directly against discoverCategories' own taxonomy listing
includePackages	bool	true	Include per-package pricing breakdown
includeFaq	bool	true	Include FAQ list
maxItems	int	20	Hard cap on emitted records (1–500)

Example: discover + fetch logo-design gigs

{
  "mode": "discoverAndFetchDetails",
  "searchKeyword": "logo",
  "maxShards": 2,
  "maxItems": 20
}

Example: fetch details for specific gig URLs

{
  "mode": "gigDetails",
  "gigUrls": [
    "https://www.fiverr.com/michael7878/master-your-song-in-1-day"
  ]
}

Example: discover sellers matching a keyword

{
  "mode": "discoverSellers",
  "searchKeyword": "design",
  "maxShards": 2,
  "maxItems": 20
}

Example: full category taxonomy tree

{
  "mode": "discoverCategories",
  "maxItems": 500
}

Example: sub-categories of one top-level category

{
  "mode": "discoverCategories",
  "category": "music-audio",
  "categoryLevel": "subCategory",
  "maxItems": 100
}

Example: discover real search-tag keywords for "tax" gigs

{
  "mode": "discoverTags",
  "searchKeyword": "tax",
  "maxShards": 2,
  "maxItems": 100
}

Reliability notes

• No login, no cookies, no API key, no paid/residential proxy — runs on the Apify free plan.
• Sitemap fetches (robots.txt, sitemap index, shard files — gig or seller) are not behind the PerimeterX challenge and are reliably Tier-1 (plain HTTP, no proxy).
• Individual gig-detail fetches use direct HTTP first and escalate to a free Apify AUTO-group proxy session only on 403, with exponential backoff on 429/5xx and a circuit breaker that stops escalating after sustained failure so a run never hangs indefinitely on a single blocked stretch.
• Because gig pages sit behind a request-velocity-sensitive anti-bot wall, per-run gig-detail yield can vary run to run; discoverGigs and discoverSellers modes (sitemap only, no per-page fetch) are unaffected and always reliable.

Use cases

• Freelance marketplace research — bulk-list live Fiverr gig and seller URLs by category or keyword to size a niche before entering it.
• Lead generation for agencies — discover seller profiles in a given category (e.g. video-animation) as an outreach or partnership list.
• Pricing intelligence — pull priceMin/priceMax/packages[] from successfully-fetched gig details to benchmark competitor pricing.
• SEO / keyword research — use discoverTags to find Fiverr's own curated, high-traffic search-tag vocabulary for a niche.
• Taxonomy / catalog mapping — use discoverCategories to get Fiverr's full category tree with real internal numeric IDs.
• Logo/brand design inspiration tools — use discoverLogoMakerIdeas to power a mood-board or naming tool with Fiverr's own curated idea taxonomy.

FAQ

Is this affiliated with Fiverr? No. This is an independent third-party actor that reads Fiverr's own public sitemap files and, best-effort, individual gig pages. It is not affiliated with, endorsed by, or supported by Fiverr International Ltd.

Why do discoverAndFetchDetails and gigDetails sometimes return 0 detail records? Fiverr's individual gig and seller-profile pages are protected by PerimeterX, which has been confirmed (via repeated live cloud runs, most recently 2026-07-26) to block every tested Apify source IP, direct and proxied alike. The actor still attempts the fetch with automatic retries and proxy escalation in case that changes, but you should treat these two modes as best-effort. discoverGigs, discoverSellers, discoverCategories, discoverTags, and discoverLogoMakerIdeas are unaffected — they read sitemap files only and are 100% reliable.

Why is there no live keyword-search mode? Fiverr's own search, category-browse, and tag-browse pages return HTTP 403 to automated traffic before any results ever render — there's no reliable way to query them from Apify infrastructure. The searchKeyword filter is a substring match against sitemap-derived slugs/usernames/titles instead, and discoverTags gives you Fiverr's own real tag vocabulary to search with.

Why are some gigDetail fields missing on a given record? Every detail field is parsed best-effort from the gig page's own structured data (JSON-LD + hydration state). Fields that aren't present or parseable on a given page are omitted — never filled with a placeholder or guessed value.

What does maxShards control, and why start at 1? Fiverr splits each sitemap into multiple gzip shard files (7 for gigs, 6 for sellers, 2 for tags). Each shard holds tens of thousands of URLs, so a single shard is usually enough to satisfy maxItems; raising maxShards widens the pool scanned before the keyword filter and maxItems cap are applied, at the cost of more download/parse time.

How fresh is the sitemap data? Fiverr regenerates its sitemap files daily, so gig/seller/category/tag listings reflect Fiverr's live catalog as of the most recent regeneration.

Are categoryId / subCategoryId / nestedSubCategoryId always present? categoryId and subCategoryId are present whenever Fiverr's sitemap or gig page exposes them (always for discoverCategories at those two levels; best-effort for gigDetail). nestedSubCategoryId is not embedded in Fiverr's own category sitemap, so discoverCategories nested-level records carry a slug only — gigDetail records can still surface it when the gig page's own hydration state includes it.

Does this actor require login, cookies, or a paid proxy? No. Every mode runs with plain HTTP requests and, only on 403 during detail fetches, a free Apify AUTO-group datacenter proxy session — no residential proxy, no cookies, no API key.