Depop Scraper Options: What Is Allowed and What Works

The most common Depop scraper advice starts with the wrong decision: which tool can extract listings fastest. Authorization comes before parser choice. A tool that returns clean product records isn’t automatically a permitted way to collect them, and a successful request doesn’t establish rights to reuse the result.

For analysts, the useful comparison is between approved access routes, their field coverage, and the operational responsibilities they leave with the buyer. Only after those constraints are settled should a team evaluate throughput, delivery formats, or whether listing observations can support a demand forecast.

Depop Scraper Routes Compared at a Glance

There isn’t a generally sanctioned public Depop scraper route. Treat any proposed collection method as unavailable until its authorization is established. The official Selling API is an integration route under Depop’s terms, not evidence that an approved account can collect arbitrary marketplace data.

The comparison below separates technical availability from permission. Read the authorization column first, field coverage second, and buyer fit last.

Depop data routes compared by authorization and fit

Route	Authorization	Fields available	Suitable for
Official Selling API	Authorized under Depop’s API terms	Product ID, SKU, price, currency, condition, colour, size, photos	Approved sellers and integrations
Written-permission data partnership	Explicit written permission with agreed scope	Set by the contract	Companies needing contracted marketplace data
Unauthorized public-site scraper	Prohibited without written authorization	Scraped page fields, unstable across site changes	Not a permitted route
Third-party marketplace actor	The same terms apply to the buyer	Only fields covered by verified collection and delivery rights	Only where the actor’s rights are verified
Managed web data service	Only after a feasibility review confirms permission	Scoped per engagement	Recurring feeds from approved sources

What each route actually solves

The Selling API addresses structured integration needs. Its field model makes it a candidate for approved seller workflows, but field availability mustn’t be mistaken for permission to retrieve every seller’s inventory.

A written-permission partnership addresses a different problem: access beyond an ordinary seller integration’s scope. The agreement should identify the marketplace coverage and permitted uses, rather than promise access to Depop data.

An unauthorized public-site scraper may appear technically capable, but it fails the initial decision screen. Comparing its export options with authorized alternatives gives it a legitimacy that technical performance alone cannot establish.

A third-party actor packages extraction logic for a buyer to run. Its presence in a tool marketplace doesn’t establish that its owner can authorize the buyer’s collection or downstream use.

A managed service changes who operates the pipeline. It doesn’t create rights over the source.

Evaluate capability only after eligibility

Once a route is eligible, assess whether it supplies the necessary attributes, preserves provenance, and supports the intended refresh schedule. A price-monitoring feed and an AI training dataset need different acceptance criteria, even if both contain product descriptions and images.

Use a structured data-extraction tool evaluation to compare schema control, observability, delivery, and maintenance, but keep authorization outside the scoring system.

Decision rule: A missing permission isn’t a weakness to offset with better pricing or broader field coverage. It’s a reason not to proceed.

The table is therefore an eligibility screen, not a ranking of scraper products. A route without written authorization isn’t usable, regardless of the fields its demonstration appears to offer.

Permission Checks Before Any Depop Collection

A publicly reachable page isn’t automatically a permitted collection target. Depop’s API terms prohibit automated systems or software used to access, analyze, or scrape the platform, API, listings, shops, or profiles unless expressly authorized in writing.

The published crawl guidance also identifies excluded or sensitive routes, including search, sold listings, likes, and account-related paths. Successful browser access doesn’t override those restrictions, and public scraping isn’t a sound basis for sold-item analysis.

Complete the permission review in order

1. Confirm written authorization and scope. Identify the authorizing party, approved accounts or marketplace coverage, permitted purposes, and any restrictions on downstream recipients. A vendor’s statement that it collects public information isn’t a substitute.

2. Check every target path. Compare the proposed source inventory with applicable crawl restrictions. If a requested route is excluded, remove it or obtain explicit clarification rather than assuming broader permission overrides the exclusion.

3. Match requested fields to approved access. The listing model covers price, currency, condition, product type, brand-related attributes, size, colour, style, shipping and address data, photos, SKU, and product ID. Include only the subset needed for the approved purpose.

4. Confirm the interface and operating limits. Use the official interface specified by the authorization and respect its applicable limits. An approved integration doesn’t imply permission to switch to undocumented endpoints when coverage is inconvenient.

5. Document retention and personal-data handling. Assign responsibility for access controls, deletion, downstream sharing, and applicable GDPR obligations for EU customer data. Don’t collect address information merely because the schema includes it.

6. Stop when access isn’t authorized. Seek permission or revise the project. Working around CAPTCHA defences or usage restrictions doesn’t resolve a missing right to collect.

Keep provider policy separate from source permission

At WebscrapingHQ, we only scrape publicly available data and respect robots.txt where applicable. We’re GDPR compliant for EU customer data, and a DPA is available on request. These policies apply within a permission the client already holds; they don’t replace Depop’s authorization.

A useful compliance record pairs each requested field with its purpose, permitted source, retention rule, and approved recipient. That makes a later expansion, such as adding seller-location attributes, a reviewable change rather than an unnoticed addition to an export.

The distinction between contractual access, privacy handling, and operational controls also matters when assessing legal risks in web scraping. Passing one check doesn’t mean the others are satisfied.

Without authorization, the appropriate deliverable is a feasibility assessment or permission-based partnership proposal, not a functioning crawler.

What Depop Data Holds at Scale

Depop’s historical marketplace figures explain why analysts are interested in its data, but they aren’t a current capacity estimate. Etsy’s acquisition announcement reported approximately 4 million active buyers and 2 million active sellers in 2020, with roughly 75% of sellers also buying and existing customer cohorts generating about 75% of total gross merchandise sales.

Those observations describe overlapping marketplace roles and repeat participation. An analyst who treats sellers and buyers as independent populations could misinterpret the relationship between supply activity and purchasing behaviour.

Design for observations over time

The relevant analytical object isn’t merely a product page. It’s a listing observed at a particular time, associated with an identifiable product and, where authorized, a seller or cohort.

For price research, preserve the observation timestamp alongside the amount and currency. For inventory research, distinguish newly observed listings from previously observed listings that have changed. For cohort analysis, document the rule used to assign membership so later refreshes remain comparable.

Historical participant counts don’t reveal current listing volume. They also don’t specify how much inventory an approved integration can access. Marketplace scale and authorized collection coverage are separate quantities.

Before estimating infrastructure, build a scope worksheet:

• Listing volume: Measure accessible inventory through the approved route rather than extrapolating from participant counts.
• Seller coverage: Record which shops or seller groups the permission includes.
• Repeat-buyer behaviour: Define whether the available observations can support this analysis at all.
• Cohort contribution: Establish whether authorized transaction evidence exists for attributing sales.
• Required freshness: Set the observation cadence from the decision the dataset must support.

A large marketplace doesn’t guarantee a representative dataset. Coverage is determined by the approved sample and the observations actually collected.

Refresh the historical baseline from authorized sources before using it in a production plan. Where participant-level or transaction evidence isn’t available, narrow the research question instead of filling those gaps with listing counts.

The Official Depop Selling API and Its Rate Limits

The official Selling API is the documented structured route for authorized integrations, not a general-purpose public search API. Depop’s API documentation describes product ID, slug, SKU, pictures, price amount, currency, product type, condition, colour, style, age, address, and description, with default limits of 20 requests per second for product creation or updates and 100 requests per second for other features.

Those rates imply the arithmetic ceilings shown below. They describe requests, not guaranteed record throughput or a promised sustained service rate.

Depop Selling API rate limits and theoretical ceilings

Limit category	Default limit	Theoretical hourly ceiling	Planning note
Product creation or update	20 requests per second	72,000 requests, calculated from the default rate	Reserve capacity for retries and throttling
Other API features	100 requests per second	360,000 requests, calculated from the default rate	Not a guaranteed sustained rate
Sustained pipeline rate	Set from measured error budget	Measured accepted requests per second multiplied by seconds per hour	Measure latency and status distribution first

Structured fields reduce the work involved in separating prices from display text, associating amounts with currencies, and mapping attributes into a destination schema. They don’t eliminate missing values or the need to validate seller-entered content.

The broader web scraping versus API comparison is useful here: structured access changes the engineering workload, but the integration’s scope still determines what can be retrieved.

Specify observability before adding workers

Reserve capacity for retries, throttling, latency variation, and errors. Increasing concurrency without measuring those conditions can produce more requests without improving delivery freshness.

Adopt a monitoring specification that includes:

• Request health: Track latency, HTTP-status distribution, retries, and throttling events.
• Response performance: Measure median and p95 latency alongside records per authorized request.
• Record quality: Monitor field completeness, duplicate rate, identifier collisions, and records requiring manual review.
• Timeliness: Record freshness lag and price-change detection delay.
• Operating tolerance: Agree an error budget and size worker concurrency against measured results.

Keep field completeness separate by attribute. A record containing a product ID and price isn’t necessarily suitable for a condition-adjusted comparison if condition is absent.

Preserve identity and auditability

Use schema-first ingestion: define field types, currency handling, null semantics, and validation rules before loading production records. Preserve stable product IDs and SKUs rather than using editable titles as record keys.

Retain raw payloads beside transformed records within the approved retention policy, and version the normalized schema. If an attribute vocabulary changes, the team can distinguish a source change from a transformation defect.

For updates, use identifiers to perform reliable upserts and maintain an observation history where permitted. Don’t overwrite the only stored price if the analytical purpose requires reconstructing changes over time.

Managed Services, Tools and Custom Builds Compared

Delivery models determine who operates the collection process and who responds when it stops producing usable records. They don’t determine whether collection is authorized. Compare responsibility explicitly rather than choosing between a convenient interface and a longer engineering project.

Responsibility across managed services, third-party actors and custom builds

Delivery model	Who holds authorization	Who maintains	What the buyer receives	What breaks first
Managed service	Client’s written permission, operated by the provider within it	Provider	Delivered feed or dataset	Source layout change, caught by provider monitoring
Third-party actor	Actor owner’s rights; the same terms still apply to the buyer	Buyer	Actor output in the actor’s own schema	Actor breaks on source change; buyer must verify rights
Custom build	Client, under its own permission	Client’s engineers	Full control over schema and quality checks	In-house team must detect drift itself

With a third-party actor, distinguish maintenance of the actor’s code from maintenance of the buyer’s workflow. Even if an actor owner publishes fixes, the buyer still needs to detect failed runs, validate exports, and adapt downstream transformations.

Compare the same operational obligations

A managed engagement places monitoring, retries, and repairs with the provider. At WebscrapingHQ, monitoring alerts our team, not the client, when a target site changes or extraction success dips. We don’t sell self-serve access to our scrapers; our operating model centres on recurring delivery.

A third-party tool packages execution but leaves the buyer responsible for determining whether its output is usable. An export can complete successfully while omitting a required attribute, so run completion alone isn’t an acceptance test.

A custom build gives engineers control over transformations, validation, and deployment. It also leaves them responsible for distinguishing source changes from genuine marketplace changes.

A useful ecommerce data-service evaluation therefore examines ownership of failures, not just supported output formats.

Apply the comparison to a source change

Suppose an approved source changes how it represents product condition. A managed team should investigate the completeness alert, adjust the transformation, and validate the repaired feed. An in-house team must implement and operate that detection process itself.

For a brand team needing weekly competitor prices, the initial scoping question is whether its written permission allows provider-operated collection. The next question is whether the feed can compare equivalent brands, conditions, sizes, and currencies without mixing unlike products.

Resellers have a related downstream problem: asking-price observations don’t establish a viable purchasing margin. ScanFlip AI’s resource, Evaluate resale profits before buying, provides relevant context for separating market observation from a purchasing decision.

The delivery model should match the team’s operational capacity. It shouldn’t be used to conceal uncertainty about source rights or analytical comparability.

Reading Depop Trend Data Without Mistaking Visibility for Demand

Secondhand apparel, accessories, and footwear exceeded 10% of total category spending in early 2026, according to Consumer Edge’s resale spending analysis. That market context makes resale observations relevant, but it doesn’t establish that a prominent Depop listing reflects completed demand.

Visibility, available supply, buyer interest, and transactions are different measures. A trend model needs to identify which one it observes before assigning commercial meaning to movement.

Identify the mechanism behind each signal

• Ranking algorithms: A listing’s position reflects selection and ordering, not a neutral sample of inventory.
• Promoted or highly active sellers: Repeated exposure can make particular stock appear disproportionately important.
• Duplicates and relisting: Repeated observations may represent the same item rather than fresh supply.
• Sold-item survivorship: The sold records available to an analyst may not represent all completed transactions.
• Seasonality: A temporary category spike can be mistaken for a durable preference.
• Search interest: Attention doesn’t establish that buyers accepted the asking price.

Sold-item analysis requires authorized access to the relevant observations. A disappearance from active inventory should remain an unknown outcome unless an approved status signal establishes what happened.

Build a defensible trend panel

Capture repeated snapshots under a consistent collection definition. Normalize brands and attributes, deduplicate images and near-identical listings, and separate active inventory from confirmed sold inventory.

Calculate sell-through proxies within comparable cohorts rather than ranking raw listing counts. Define cohorts using attributes relevant to the question, such as category, condition, and observation period, and disclose which outcomes remain unobserved.

More listings can indicate greater supply, slower clearance, or broader collection coverage. It doesn’t establish stronger demand by itself.

For market trend analysis, maintain a record of collection changes alongside the marketplace observations. Otherwise, an expanded sample can look like category growth.

Treat Depop as a selective cultural-signal panel, not a census of resale demand. Retail, CPG, and AI teams should compare its signals with broader resale evidence before applying them to a wider population. Where the available evidence supports only visibility analysis, label the output accordingly rather than presenting it as a sales forecast.

Confirm Permission Before You Build a Depop Pipeline

Choose the available route before commissioning extraction work. The authorization request should specify the collection purpose, source coverage, requested fields, frequency, retention, and intended recipients. For model-development projects, include the proposed training use explicitly rather than assuming analytical access includes it.

Depop data need by situation

Situation	Route	First action
Managing your own Depop shop	Official Selling API	Confirm API access on your account
Tracking competitor listings for a brand	Written-permission data partnership	Request written authorization covering fields and frequency
Trend research on Depop listings	Permission-based partnership after feasibility review	Define sell-through proxies and comparison data first
AI training data from Depop	Authorized dataset only	Confirm rights and privacy obligations before collection
One-off or ad hoc collection	No route without authorization	Request permission from Depop; do not scrape

Turn approval into a build specification

Once permission exists, conduct a feasibility review against the actual target sources. Translate the approved scope into field definitions, quality checks, delivery expectations, and stop conditions. If a required observation isn’t accessible, revise the analysis before committing engineering resources.

We’ve run production scraping stacks since 2019. For teams that already hold permission, that operational background is relevant to scoping, schema design, monitoring, and recurring delivery. It isn’t evidence of a ready-made Depop scraper product, and no such product should be assumed to exist.

We don’t undertake one-time scrapes or one-off projects. An ad hoc need therefore requires a different delivery arrangement, even when collection is authorized.

This week, draft the authorization request. List the exact fields and collection frequency it must cover, identify the intended use, and record how long each category of information will be retained.

---

WebscrapingHQ offers permission-scoped feasibility reviews, custom schema design, and managed pipelines for recurring structured-data delivery. If you already hold written authorization for Depop collection, visit WebscrapingHQ with your approved scope, required fields, and refresh schedule to assess a maintainable pipeline.