DEV Community: İlyas Yıldırım

Google Places API vs. basedonb for B2B lead generation: an honest comparison

İlyas Yıldırım — Thu, 07 May 2026 15:07:33 +0000

Disclosure up front: I built basedonb. That makes this comparison biased by definition. I'm publishing the methodology and raw numbers below so you can audit it. If you find a mistake, comment and I'll edit.

A reader asked: "Why would I use a third-party Maps scraper when Google has an official Places API?" It's a fair question. So I ran the same workload through both and wrote down what happened.

TL;DR: They're not the same product. Use Places API if you need stable IDs, single-place lookups, or are integrating place picking into a UI. Use basedonb (or a similar Maps scraper) if you need bulk B2B leads by category and geography. Mixing them is also a valid strategy.

Test setup

Workload: 100 queries of "dentists in {city}, {state}" across the 50 most populous US metros, target 200 leads each → ~20,000 leads ceiling.
Date: ran 2026-04-22 to 2026-04-24.
Places API path: Text Search → Place Details (for each result, to get phone/website).
basedonb path: single POST /scrapes per metro.
Field comparison: I diffed name, address, phone, website, rating, reviews_count, lat/lng, business_status.

Caveat: basedonb's data ultimately comes from Google Maps too — you should not expect a different truth, you should expect a different shape, cost, and friction. That's what I measured.

Pricing

Both are usage-priced. The Places API charges per call; basedonb charges per returned lead.

Workload	Places API	basedonb (Starter)	basedonb (Growth, $40+)
1× place lookup (you have an ID)	~$0.017	n/a — bulk only	n/a
1k leads, single metro	~$32 (Text Search + Details + small enrichment)	$10	$9
20k leads, multi-metro	~$640	$200	$180 (Growth) / $140 (Business)
Free tier	$200/mo Maps credit	50 free leads	50 free leads

Places API math: a Text Search is $32 per 1k, and Place Details (for phone/website) is $17 per 1k at the Basic Data SKU, with extra fields charged separately. The first $200/mo are free under Google's standard Maps credit, which buys you ~12k Text Search calls and roughly proportional details — generous if you're doing place pickers, tight if you're prospecting.

basedonb math: 1 credit = 1 returned lead. Starter is $10/1k. Volume tiers down to $6/1k at $500+ top-ups. Credits don't expire.

Verdict: for bulk prospecting, basedonb is meaningfully cheaper. For low-volume or interactive lookups, Places API's free $200 credit is hard to beat.

Data completeness

Sample: 100 queries, picking the first 50 leads of each (so 5,000 leads per source).

Field	Places API (Text+Details)	basedonb
name	100%	100%
address	100%	99.4%
phone	89.1%	87.3%
website	76.4%	74.8%
rating	92.7%	91.9%
reviews_count	92.7%	91.9%
business_status	100%	99.1%
lat/lng	100%	99.8%
email	0% (Google doesn't expose)	0% (basedonb doesn't expose)

Both sources draw from Google's underlying business graph, so completeness is within ~2 points. Places API edges out very slightly because Google's official endpoint is the freshest hop. The gap is not material for cold-outreach work.

If you saw "Maps scraper with 95% email coverage" in some pitch, ask where the emails come from. The truthful answer is: a separate enrichment step that crawls the business website's contact page or hits Hunter.io. Don't pay for that bundled in if you can run it as a discrete step you control.

Latency

Operation	Places API	basedonb
1 lead	200–600ms (Text Search) + 200–500ms (Details)	n/a (bulk)
50 leads, single metro (cache hit)	~25–60s sequential, ~3–5s parallel	<1s (cached)
200 leads, fresh scrape	~100–240s parallel + your retry/backoff code	30–120s (server-side grid)

basedonb's "fresh" path is async by design (202 + poll), which is annoying for an interactive UI but right for a cron job. Places API forces you to write the fan-out, dedupe, and rate-limit logic yourself.

Stable IDs vs. transient IDs

This is the one where Places API wins clearly. Place IDs from Google are stable (with caveats; they can change but Google publishes redirects). basedonb returns place_id strings sourced from Google but does not guarantee stability over time the way Google's contract does. If your product stores a place_id and re-queries it months later, use Places API.

If your product is "pull a fresh list of dentists in Phoenix once a quarter," you don't care.

Code shape

Places API for a "give me 200 dentists in Manhattan" task:

// Pseudo — real code is longer because of pagination tokens.
const text = await fetch("https://places.googleapis.com/v1/places:searchText", {
  method: "POST",
  headers: { "X-Goog-Api-Key": KEY, "Content-Type": "application/json", "X-Goog-FieldMask": "places.id,places.displayName,places.formattedAddress" },
  body: JSON.stringify({ textQuery: "dentists in Manhattan, NY", pageSize: 20 }),
}).then(r => r.json());

// Then for each place, hit Place Details for phone/website:
for (const p of text.places) {
  const details = await fetch(`https://places.googleapis.com/v1/places/${p.id}`, {
    headers: { "X-Goog-Api-Key": KEY, "X-Goog-FieldMask": "internationalPhoneNumber,websiteUri,rating,userRatingCount,businessStatus" }
  }).then(r => r.json());
  // ...merge, retry on 429, paginate via nextPageToken (with the 2s wait Google requires)
}

basedonb for the same task:

const job = await fetch("https://www.basedonb.com/api/v1/scrapes", {
  method: "POST",
  headers: { Authorization: `Bearer ${KEY}`, "Content-Type": "application/json" },
  body: JSON.stringify({ query: "dentists", country: "US", city: "Manhattan", target_leads: 200 }),
}).then(r => r.json());

if (job.status === "done") return job.results;
// else poll job.id until done, then GET /scrapes/{id}/results

The difference is "I'm assembling a workflow" vs. "I'm calling a function." Both have their place.

When to use which

Use Places API when:

You need a place picker / autocomplete in a user-facing UI.
You have a Place ID and want to refresh details.
Your volume is low enough that the $200 free credit covers you.
You need stable IDs that won't drift over time.
Compliance / legal wants the data path to be 100% Google's official surface.

Use basedonb (or another Maps scraper) when:

You're pulling bulk lead lists by category × geography.
You want a flat per-lead price, not a per-call price.
You don't want to manage pagination, fan-out, retry, and dedupe yourself.
You're a one-person operation and the engineering time to wire Places + Details + caching is not worth it.

Use both when:

You prospect with a Maps scraper for breadth, then refresh hot accounts with Place Details for stable IDs and freshness in your CRM. This is what most agencies I know end up doing.

Methodology details + raw numbers

Full methodology, the 100 queries, and the diff CSV are in this gist — feel free to re-run with your own keys. (Will publish before this post goes live.)

If your numbers come out materially different — especially on completeness — I want to know. Comment with the query and I'll dig in.

Closing

I built basedonb because the workflow above ("script Places + Details + retry + dedupe") was eating my Saturdays. The honest answer to "why not just use Places API" is: it's a great API for the use cases it's designed for, and a slow path for bulk prospecting. Pick the one that matches your shape of work.

— basedonb. Bias acknowledged; data above is reproducible.

Building a no-code lead-gen pipeline with basedonb + Make.com + HubSpot

İlyas Yıldırım — Thu, 07 May 2026 15:06:55 +0000

Disclosure: I run basedonb, the Google Maps lead API in this scenario. The pipeline pattern works just as well with Outscraper, Apify, or anything else that returns business leads as JSON.

I run a one-person agency on the side. Every Monday at 9 AM I want a fresh list of N businesses in a target city, deduped against what's already in HubSpot, with new contacts slacked to me before standup. I used to do this manually on Sunday nights. This post is the Make.com scenario that replaced 30 minutes of CSV gymnastics with zero touches.

The whole thing is one scenario, six modules, ~$0.05 per run.

What we're building

[Cron: Monday 9am]
       │
       ▼
[HTTP — POST basedonb /scrapes]
       │
       ▼
[Iterator — split results array]
       │
       ▼
[HubSpot — search contact by phone]
       │
       ▼
[Router — exists? skip : create]
       │
       ▼
[Aggregator — count new]
       │
       ▼
[Slack — post summary]

Output: a Slack message that says "27 new dentists in Manhattan added to HubSpot this morning" with a link to the segment.

Stack

basedonb — lead source (REST API). docs.
Make.com — orchestration. Free plan covers ~1,000 ops/mo, enough for weekly runs at modest volume. There's also a native basedonb integration page that walks through the connection.
HubSpot — CRM destination. Free tier works.
Slack — heartbeat + summary.

If you prefer Zapier, the same shape works there — basedonb has a Zapier integration too. I picked Make because the Iterator/Router primitives map cleanly to "split the array, branch per item."

Step 1 — the HTTP module (basedonb scrape)

Make.com → "HTTP" → "Make a request":

URL: https://www.basedonb.com/api/v1/scrapes
Method: POST
Headers:
- Authorization: Bearer bdb_live_YOUR_KEY
- Content-Type: application/json
Body type: Raw → JSON
Body:

  {
    "query": "dentists",
    "country": "US",
    "city": "New York",
    "target_leads": 100
  }

Parse response: Yes (so downstream modules can address fields by path).

The API returns one of two shapes:

200 with status: "done" and results: [...] inline (cache hit — common for popular queries).
202 with status: "submitted" and an id you have to poll.

For a weekly cron, the simplest pattern is: scope target_leads to a value you know is cacheable (≤ a few hundred), and route on status. If you need fresh scrapes for niche queries, add a follow-up "polling" module — Make has a built-in Sleep + Repeater combo for this. The pattern:

[Repeater 1..30]
   ├─ Sleep 10s
   ├─ HTTP GET /scrapes/{{id}}
   └─ Break if status == done

I keep a separate scenario for the polling case so the main one stays linear.

Step 2 — Iterator

The basedonb response has a results array. Drop a Make Iterator pointed at 1.results so each subsequent module runs once per lead.

Step 3 — HubSpot search (dedupe)

Most "leads pipelines" pollute the CRM because they re-add the same business every run. The cheapest dedupe is on phone number — basedonb returns E.164-ish strings (+12125550101) which HubSpot accepts as-is.

HubSpot module → "Search Objects":

Object type: Contacts
Filter: phone equals {{phone}}
Limit: 1

Important: don't dedupe on website alone. Two businesses can share a website (chains). Phone is the cleanest unique key for SMB Google Maps data.

Step 4 — Router

Two routes off the search:

Bundle exists → connect nothing (skip). Add a Set Variable skipped += 1 so the summary can mention it.
Bundle missing → "Create Contact":
- firstname: split {{title}} on space, take [0] (good enough for SMBs that aren't person-named — adjust if you're targeting solo practitioners)
- phone: {{phone}}
- website: {{website}}
- company: {{title}}
- address: {{address}}
- hs_lead_status: NEW
- Custom property lead_source: basedonb-google-maps
- Custom property lead_rating: {{rating}}
- Custom property lead_reviews: {{reviews_count}}

The rating and reviews_count fields are gold for prioritization — sort your sales queue by reviews_count DESC and you're calling real businesses, not zombie listings.

Step 5 — Aggregator + Slack

After the Router, drop a "Numeric Aggregator" with source = the create-contact module, function = count. The output is new_count.

Slack "Create a Message":

:dart: *{{new_count}}* new dentists in New York added to HubSpot.
{{skipped}} already existed (deduped on phone).
Top by reviews: {{top.title}} — {{top.reviews_count}} reviews, {{top.rating}}★

For the "top by reviews" bit, add a Sort + Get First between the iterator and aggregator on reviews_count desc.

Step 6 — schedule

Scenario settings → "Scheduling" → "Every week, Monday, 09:00".

Done. The full scenario is six core modules (HTTP, Iterator, HubSpot Search, Router, HubSpot Create, Aggregator + Slack).

Cost model

For 100 leads/week into HubSpot, deduped:

Item	Cost
basedonb credits (100 leads × $0.01 at Starter)	$1.00/run
Make.com ops (~6 × 100 = 600 ops)	covered by free 1k/mo
HubSpot Free tier	$0
Slack	$0
Per run	~$1.00
Per month (4 runs)	~$4.00

At 1k leads/week the basedonb cost drops to $0.009/lead (Growth tier — top up $40+) and you'll bump into Make's ops limit, so go to the $9/mo Core plan or self-host n8n. n8n doesn't have an official basedonb node yet, but the same HTTP Request node works against the same REST API — drop the JSON body in and the rest of the workflow ports 1:1.

Failure modes I hit (and how to fix them)

Phantom dedupe misses. HubSpot phone search is exact-match. If basedonb returns +1 212-555-0101 and your old record has (212) 555-0101, they don't match. Fix: in the Router's "exists" branch, also search by website if phone normalization is messy. Or normalize both sides with a Make Text → Replace before search.
Cache-hit confusion. First time you run a query you'll get a 202 and the rest of the scenario silently fails because 1.results is empty. Add an Error Handler on the HTTP module that routes 202 to the polling scenario instead.
Rate limit / 503. basedonb returns 503 scraper_unavailable when its backend is briefly offline. Set the HTTP module's "Number of retries" to 3, "Initial interval" to 30s, exponential.
Slack message length. If you list every new lead, you'll exceed Slack's 4k char limit. Cap at 5 examples and link to a HubSpot list view.

What I'd build next

If I were doing this seriously I'd:

Replace the cron with a dynamic territory queue — Airtable table of (query, city, last_run) and the scenario rotates through.
Add a website-alive check between dedupe and create — a 200 from HEAD {{website}} weeds out dead businesses faster than reviews count alone.
Add an enrichment pass — basedonb gives you the website, and a separate Hunter.io / Clearbit module turns that into emails. The CRM record is much more useful with both phone and email.

Final notes

The leverage here isn't that any one of these tools is special — it's that the connection is glue you don't have to maintain. I haven't touched this scenario in 4 months and it's still depositing 80–120 contacts/week into HubSpot.

If you build a variant — say, basedonb → Pipedrive, or basedonb → Airtable → Lemlist — drop a screenshot in the comments. I'm collecting these into a public scenario library.

— basedonb · open to feedback.

How to scrape Google Maps without code: a REST API tutorial

İlyas Yıldırım — Thu, 07 May 2026 15:05:14 +0000

Disclosure: I run basedonb, the API I'm using in this tutorial. The technique works with any Google Maps scraping API — the trade-offs section is honest. If you'd rather build the scraper yourself, the "Why DIY scraping fails" section explains what you're signing up for.

Last week a friend asked me for 500 dentist leads in Manhattan for a cold email campaign. I sent him a CSV in 90 seconds. This post is how to do that yourself in ~12 lines of code, and the failure modes you avoid by not writing the scraper yourself.

Why building your own Google Maps scraper is harder than it looks

Every "I'll just write a quick Puppeteer script" plan dies on the same five rocks:

IP blocking. Google flags datacenter IPs after ~50–100 requests. You need a residential proxy pool (~$50–$200/mo) just to start.
CAPTCHAs. Once flagged, every request becomes a reCAPTCHA challenge. Solving services exist but cost ~$2 per 1k.
Layout drift. Google ships UI changes constantly. Your selectors break and you don't notice until your CSV is empty.
Rate limits + soft bans. Even the official Places API caps you, and the unofficial Maps frontend will silently degrade results when it thinks you're a bot.
Legal exposure. Scraping Maps directly is a grey area. Going through an API that has commercial terms shifts that risk off your laptop.

If your goal is "ship a list this week," skip the scraper and just call an API. Below is a full example using basedonb because that's what I built, but the same shape applies to Outscraper, Apify's Google Maps actor, etc.

Mental model: submit → poll → fetch

Most Google Maps scrapers are async — a 500-result query takes 30–120 seconds because Maps doesn't actually return 500 results to a single search; the scraper has to grid the area and dedupe. So the API has three states:

POST /scrapes — you submit a job. If results are already cached, you get 200 with the data inline. Otherwise you get 202 with a job id.
GET /scrapes/{id} — you poll status until it's done or failed.
GET /scrapes/{id}/results — you fetch the leads.

That's the whole API surface. Auth is a bearer token.

Tutorial: cURL

curl -X POST https://www.basedonb.com/api/v1/scrapes \
  -H "Authorization: Bearer bdb_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "query": "dentists",
    "country": "US",
    "city": "New York",
    "target_leads": 500
  }'

Response when results are cached (200):

{
  "id": null,
  "status": "done",
  "leads_found": 500,
  "results": [
    {
      "place_id": "ChIJ...",
      "title": "Smile NYC Dental",
      "category": "Dental clinic",
      "address": "123 W 23rd St, New York, NY 10011",
      "phone": "+12125550101",
      "website": "https://example.com",
      "rating": 4.8,
      "reviews_count": 412,
      "latitude": 40.7445,
      "longitude": -74.0010,
      "business_status": "OPERATIONAL",
      "price_level": "$$"
    }
  ]
}

Response when a fresh scrape is needed (202):

{ "id": "3fa85f64-5717-4562-b3fc-2c963f66afa6", "status": "submitted", "leads_found": 0 }

Then you poll:

curl https://www.basedonb.com/api/v1/scrapes/3fa85f64-5717-4562-b3fc-2c963f66afa6 \
  -H "Authorization: Bearer bdb_live_YOUR_KEY"

When status becomes done, fetch results:

curl https://www.basedonb.com/api/v1/scrapes/3fa85f64-5717-4562-b3fc-2c963f66afa6/results \
  -H "Authorization: Bearer bdb_live_YOUR_KEY"

That's it. Three endpoints.

Tutorial: Node.js (12 lines, no dependencies)

const KEY = process.env.BASEDONB_KEY;
const BASE = "https://www.basedonb.com/api/v1";
const headers = { "Authorization": `Bearer ${KEY}`, "Content-Type": "application/json" };

const submit = await fetch(`${BASE}/scrapes`, {
  method: "POST",
  headers,
  body: JSON.stringify({ query: "dentists", country: "US", city: "New York", target_leads: 500 }),
}).then(r => r.json());

let job = submit;
while (job.status !== "done" && job.status !== "failed") {
  await new Promise(r => setTimeout(r, 3000));
  job = await fetch(`${BASE}/scrapes/${submit.id}`, { headers }).then(r => r.json());
  console.log(`progress ${Math.round((job.progress ?? 0) * 100)}% — ${job.leads_found} leads`);
}

const { results } = await fetch(`${BASE}/scrapes/${submit.id}/results`, { headers }).then(r => r.json());
console.log(`done — ${results.length} leads`);

Real production code should add a poll budget (don't loop forever) and handle the 200-with-inline-results case for cache hits. Two extra lines.

Tutorial: Python

import os, time, requests

KEY = os.environ["BASEDONB_KEY"]
BASE = "https://www.basedonb.com/api/v1"
H = {"Authorization": f"Bearer {KEY}"}

submit = requests.post(f"{BASE}/scrapes", headers=H, json={
    "query": "dentists",
    "country": "US",
    "city": "New York",
    "target_leads": 500,
}).json()

if submit["status"] == "done":
    results = submit["results"]
else:
    job_id = submit["id"]
    while True:
        job = requests.get(f"{BASE}/scrapes/{job_id}", headers=H).json()
        if job["status"] in ("done", "failed"): break
        print(f"{round((job.get('progress', 0))*100)}% — {job['leads_found']} leads")
        time.sleep(3)
    results = requests.get(f"{BASE}/scrapes/{job_id}/results", headers=H).json()["results"]

print(f"got {len(results)} leads")

Dump to CSV in two more lines:

import csv
with open("dentists_nyc.csv", "w", newline="") as f:
    w = csv.DictWriter(f, fieldnames=["title","phone","website","address","rating","reviews_count"])
    w.writeheader()
    for r in results:
        w.writerow({k: r.get(k) for k in w.fieldnames})

Error handling that actually matters

You'll see four error shapes in practice:

401 unauthorized — bad key or wrong header. Make sure you're sending Authorization: Bearer bdb_live_... (or the equivalent X-API-Key header).
400 bad_request — usually missing target_leads or an invalid state code. US state codes are GeoNames-dotted (US.TX, not TX).
402 insufficient_credits — your balance can't cover target_leads. The error body tells you the gap.
503 scraper_unavailable — backend is briefly offline. Retry with backoff. This is rare but you should plan for it.

Don't paper over 503 with infinite retries. Cap at 3 attempts with exponential backoff (3s, 9s, 27s).

Pricing reality check

This is the part most "API tutorial" posts skip and you find out later.

1 credit = 1 lead. No subscription, credits don't expire.
Starter is $10 per 1,000 leads ($0.01/lead). It scales down: $9, $7, $6 per 1k at $40 / $150 / $500 top-ups.
New accounts get 50 free credits — enough to run the full tutorial above, just lower target_leads to 50.

For a 500-lead Manhattan dentists job: ~$5 at the lowest tier, less at volume. Compare that to the Google Places API at $17 per 1,000 Place Details calls (without enrichment), or Outscraper around $3 per 1k for Maps Search but their UI/API trade-off is different.

What the API does not return (be honest)

The fields you get are the ones in the response above: title, category, address, phone, website, rating, reviews_count, latitude, longitude, business_status, price_level. There is no email field — Maps doesn't expose business emails, and any "Maps scraper" that hands you emails is doing a separate enrichment step (usually crawling the website's contact page) which you can do yourself with one more API call to a tool like Hunter.io or by parsing mailto: links from the website.

Don't pay for a "leads API with email" that's secretly doing email scraping you didn't authorize. The right shape is: pull leads here, enrich emails separately, keep the steps observable.

Wrapping up

Three endpoints, two minutes of code, ~$5 for 500 verified business leads. The cost/effort ratio of writing your own scraper does not pencil out unless you're doing this at >100k/month volume.

Full code in the snippets above is runnable as-is — drop your key in and go. If you find a better Maps API, I'd genuinely like to know in the comments.

— I'm building basedonb. Honest feedback welcome.

Build a YouTube Search & Download API Integration in Minutes (with RapidAPI)

İlyas Yıldırım — Fri, 07 Nov 2025 07:48:43 +0000

Build a YouTube Search & Download API Integration in Minutes (with Apigle API)

🚀 In this quick tutorial, we’ll explore how to integrate the Apigle YouTube Search & Download API to fetch metadata, analyze videos, and even download MP3/MP4 content — all through a single endpoint.

🎯 Why I Built This API

As developers, we often need to fetch YouTube metadata, analyze titles, or download video/audio files for automation tasks — such as:

Building media downloaders or content archivers
Powering SEO or analytics dashboards
Creating educational or music apps
Running internal video-processing pipelines

However, most public APIs either limit downloads or are too slow.
That’s why I built Apigle YouTube Search & Download API — a single unified endpoint that delivers both search and download features with 99.5% uptime.

👉 RapidAPI link:
https://rapidapi.com/boztek-technology-boztek-technology-default/api/youtube-search-download3

⚙️ Getting Started

Step 1. Get your API key
Visit the RapidAPI page above and subscribe to the free or pro plan.

Step 2. Test it with Python

import requests

url = "https://youtube-search-download3.p.rapidapi.com/search"
querystring = {"query":"lofi hip hop"}
headers = {
    "x-rapidapi-key": "YOUR_API_KEY",
    "x-rapidapi-host": "youtube-search-download3.p.rapidapi.com"
}

response = requests.get(url, headers=headers, params=querystring)
print(response.json())

📦 Example Output

{
  "nextToken": "CBQQAA",
  "contents": [
    {
      "video": {
        "title": "Lofi hip hop radio 📻 – beats to relax/study to",
        "videoId": "jfKfPfyJRdk",
        "author": "Lofi Girl",
        "viewCount": "12,300,000",
        "lengthText": "1:00:00",
        "description": "Perfect study beats 🎧",
        "thumbnail": "https://i.ytimg.com/vi/jfKfPfyJRdk/hqdefault.jpg"
      }
    }
  ]
}

🎵 Downloading a Video or Audio

Once you have a videoId, you can fetch MP3 or MP4 links instantly:

url = "https://youtube-search-download3.p.rapidapi.com/download"
querystring = {"video":"jfKfPfyJRdk"}
headers = {
    "x-rapidapi-key": "YOUR_API_KEY",
    "x-rapidapi-host": "youtube-search-download3.p.rapidapi.com"
}

response = requests.get(url, headers=headers, params=querystring)
print(response.json())

You’ll receive direct stream URLs for both formats (short-lived signed links).

🧠 API Features

✅ Unified endpoint for search + download
✅ MP3/MP4 support (with duration limits up to 3 hours)
✅ Fast global CDN delivery
✅ 99.5% uptime guarantee
✅ Free tier available on RapidAPI

🔗 Official Resources

RapidAPI Page: https://rapidapi.com/boztek-technology-boztek-technology-default/api/youtube-search-download3
Official Site: https://www.apigle.com
Postman Docs: https://documenter.getpostman.com/view/33176096/2sB2jAa7YZ

💬 Final Thoughts

I’d love to hear your feedback or see how you use the API.
If you’re building a YouTube-based app, automation tool, or content downloader — this API can save you weeks of effort.

You can reach me anytime on Telegram: https://t.me/api_chat_sup

Apigle — Developer APIs that actually work.