Under maintenance

Pricing

from $1.00 / 1,000 result emitteds

Try for free

Go to Apify Store

Kick Chat Scraper & Real-Time Archive

Under maintenance

Try for free

Archive live Kick.com chat via the Kick chat API — subscribe to one or more channels and capture every message with sender, role, badges, and timestamp, export to JSON or CSV. Kick has no native chat history, so this is the way to keep a record.

Pricing

from $1.00 / 1,000 result emitteds

Rating

0.0

(0)

Developer

DevilScrapes

Actor stats

Bookmarked

Total users

Monthly active users

6 hours ago

Last modified

Kick.com Chat Archive — Changelog

0.11 — 2026-08-17

Daily signal:
```
publicActorRunStats30Days = {FAILED: 1, SUCCEEDED: 6, TIMED-OUT: 21, TOTAL: 28}
```
(78.6% failure) — the fleet-wide health sweep's #3 worst Actor by lost customer runs (ops/FLEET-HEALTH-TRIAGE-2026-08-17.md). Build 0.10.1 (the dynamic-deadline fix) had already been live since 2026-08-15 08:25, and the 2026-08-15/16 CEO reports show the failure rate did not clear afterward (08-16: "22/23 failures are HANGS, not errors") — direct evidence the 0.10 fix, while real, was not the whole story. Own runs (3 total, all SUCCEEDED) give no visibility into the failing customer runs (reference-fleet-health-signal), so this session is pure local reproduction against real Kick.com traffic, per reference-fleet-fault-isolation-pattern.
Root cause found — CONFIRMED by direct local reproduction, three variants: src/ws_client.py::listen()'s connect + initial-handshake phase (async with websockets.connect(...) as ws: and the immediately following ws.recv() for Pusher's connection_established frame) had no exception handling at all — the one connection phase in this module that v0.5/v0.7/v0.9 never hardened, even though every other I/O site (send, recv-loop, subscribe) already has a bounded, graceful-failure contract. Reproduced with a local websockets.serve() mock Pusher server standing in for the real one:
1. Peer accepts the connection then closes without sending anything → unhandled websockets.ConnectionClosedOK.
2. Peer accepts the connection but never sends the first frame → unhandled TimeoutError (bounded by PUSHER_CONNECT_TIMEOUT_S, but not caught).
3. Endpoint unreachable/refused (DNS failure, network blip, Pusher-side outage) → unhandled OSError.
All three crash the entire Actor run with an uncaught exception instead of the graceful outcome the code clearly intends:
```
stats. connected
```
stays False, main.py's existing REQ-13 check fires, and the run exits 1 with "Could not establish a live chat subscription" — a clear, billed-but-honest failure message instead of a raw traceback. Since Actor.charge("actor-start", ...) fires before any of this runs, every one of these was already a customer billed for nothing before the crash.
Honest scope — what this does and does not explain: an uncaught exception inside async with Actor: produces a fast FAILED exit, not the TIMED-OUT (platform force-kill after exceeding the run's wall-clock budget) that dominates this Actor's current 30-day stats (21 of 22 failures). This fix is CONFIRMED to close a real, previously-uncaught crash class with three concretely reproduced trigger conditions, and HYPOTHESIS (not proven) that it explains any share of the TIMED-OUT majority specifically — plausible if the Apify SDK's own exception-path shutdown inside async with Actor: doesn't itself return quickly, but that mechanism was not directly observed this session. websockets' connect-side WS traffic also carries no browser-like fingerprint (default User-Agent: Python/websockets), unlike every other network surface in this Actor (api_client.py rotates curl-cffi browser impersonation) and the fleet's anti-blocking stack — a plausible, not confirmed, reason a datacenter-IP handshake to Pusher gets rejected/dropped more often than a browser's would.
What was tried and did not explain the TIMED-OUT majority: re-audited every wall-clock cap in main.py/ws_client.py (RESOLVE_PHASE_MAX_S, RECV_CHUNK_S, SEND_TIMEOUT_S, PUSHER_CONNECT_TIMEOUT_S, DURATION_MAX_S, DEADLINE_SAFETY_MARGIN_S) and the 0.10 Actor.configuration.timeout_at plumbing directly against the installed apify==3.4.0 SDK source (_configuration.py) — the env-var aliases (ACTOR_TIMEOUT_AT/ APIFY_TIMEOUT_AT) are real and resolve correctly when set, so the 0.10 fix is not a silent no-op. No local reproduction attempt (see below) triggered an actual local hang past its expected bound.
What was tried and could not be reproduced locally: live Kick.com traffic (real network calls against kick.com/Pusher, not mocked) — xqc, kaicenat, adinross, ninja, trainwreckstv, nadia, stableronaldo, buddha, n3on, iceposeidon, fousey, agent00, duke_dennis, sketch, mikelong, elonmusk, amouranth, asmongold, ibai, loltyler1, plus 404s (some-definitely-fake-slug, sneakobrown, plaqueboymax, yeezuz) to exercise REQ-1 slug-miss handling. None were live at request time (2026-08-17 ~11:00 UTC), so the "huge chat volume" and "non-English chat" scenarios in this session's brief could not be driven with real traffic; Kick's public API surface offers no reliable "currently live, high-viewer-count channel" listing endpoint to target one deterministically. A real apify run against tests/fixtures/input.qa.json (xqc, offline) confirms the happy/quiet path is unaffected by this fix: resolved <1s, connected, subscribed, ran the full 30s window, exited 0 with the expected message.
Fix: src/ws_client.py — new CONNECTION_ERRORS tuple (OSError, TimeoutError, websockets.WebSocketException) wraps the entire async with websockets.connect(...) block in listen(); the initial-handshake logic is extracted to _establish() so listen() stays under the 40-line function ceiling. Any connection-establishment failure is logged and swallowed exactly like a same-effect "never connected" outcome, leaving stats.connected=False for the caller's existing fail-loud gate.
New regression tests (tests/test_ws_client.py, 3 new, all verified to fail against the pre-fix source with the exact three exception types above, and pass after): test_listen_survives_peer_closing_before_any_frame, test_listen_survives_peer_never_sending_first_frame, test_listen_survives_connection_refused — each spins up a real local websockets.serve() mock Pusher server (not a fake object) so the regression exercises the actual websockets connect/handshake code path, not just a mocked substitute.
Local gates: ruff check src/ tests/ clean. pyright (via uvx, not added as a project dependency) — 1 pre-existing error only (tests/test_models.py:63, the documented Pydantic-Field-default false positive since 2026-07-10). pytest tests/: 57/58 green (54 pre-existing
- 3 new); the 1 failure (test_pay_per_event_declared) is the same pre-existing, unrelated $0.05 fleet-pricing-standard gap flagged in every prior session on this Actor — not fixed here (repricing has its own 14-day-notice constraint).
Twitch sibling check (actors/twitch-vod-chat-archive, not modified): does not share this flaw. It has no WebSocket/live-connection code at all — it archives already-recorded VOD chat via paginated Twitch GQL HTTP POSTs (src/client.py::gql_post), and that retry loop already wraps every network call in try/except (RequestsError, OSError) with backoff, returning (None, reason) instead of raising. The two Actors share a name pattern ("chat archive") but not an architecture — Kick has no chat-history API, so this Actor is necessarily live-only over a persistent WebSocket; Twitch's VOD replay is a fundamentally different, already-hardened, one-shot-HTTP-per-page design. No action needed on Twitch from this session's finding.
Budget note: no cloud run was used this session (mid-session instruction withdrew the previously-allowed single small cloud run, account at $3.79/$5.00). This fix is local-reproduction-verified only; it has not been cloud-QA'd. The specific thing a cloud run would need to prove that local reproduction cannot: whether the TIMED-OUT majority itself clears once this build is live, since local runs never experience an actual Apify platform force-kill.

0.10 — 2026-08-13

Daily signal (measured 2026-08-13, GET /v2/acts/Sb8LSyiJ0UZfwdxad):
```
publicActorRunStats30Days = {FAILED: 1, SUCCEEDED: 6, TIMED-OUT: 25, TOTAL: 32}
```
— 78% of customer runs TIMED-OUT. Compared against the prior six sessions' snapshots (see docs/specs/kick-chat-archive/notes.md), this is not simply the same stale window continuing to age out: stats.lastRunStartedAt = 2026-08-11T14:45:16Z, i.e. a run (not ours — our own /acts/{id}/runs shows only 3 owner runs, none since 2026-08-06) landed after build 0.8.1 (finished 2026-08-06, the live build for this whole window) went live. The "aging legacy timeouts, no new failures" verdict from the five prior sessions (2026-07-10 through 2026-08-12) cannot be extended to cover that run without more direct evidence, and this Actor's near-zero user count (totalUsers30Days: 1) means a single customer's usage pattern dominates the whole stat — worth re-auditing for a class of hang none of the prior five sessions checked for.
Root cause found: every prior TIMED-OUT fix on this Actor (v0.4-v0.9) bounded the WebSocket listen window against a static assumption of the Apify platform's kill timer — DURATION_MAX_S=3540s vs. a hardcoded belief that defaultRunOptions.timeoutSecs=3660s always applies. That assumption breaks whenever the actual run is started with a tighter platform timeout than the Actor's own default — routine for schedulers, webhooks, and third-party no-code integrations (Zapier/Make/n8n-style connectors commonly default an actor-run timeout far below an hour). This Actor's normal use case (archive a whole stream) means most successful runs already try to use the entire requested maxDurationSeconds window — the single highest-exposure design in the fleet for exactly this class of caller-timeout mismatch, and invisible to every prior fix because none of them ever read the platform's actual per-run deadline. Apify exposes it via the APIFY_TIMEOUT_AT/ACTOR_TIMEOUT_AT env var, surfaced by the SDK as Actor.configuration.timeout_at — unused by this Actor's code until now.
Fix: src/main.py::_seconds_until_deadline() reads Actor.configuration.timeout_at and returns the real seconds remaining until the platform force-kills the run (None on local runs — no env var set, so local behaviour is unchanged). compute_listen_budget_s() gained a third, independent ceiling — deadline_remaining_s minus a new DEADLINE_SAFETY_MARGIN_S=30s flush buffer — so the listen window can never outlive the actual platform deadline, regardless of what maxDurationSeconds was requested or what this Actor's own defaultRunOptions.timeoutSecs default is. A run whose caller supplied a tight timeout now exits cleanly via the Actor's own bounded exit path well before the platform force-kills it — trading a small amount of listen time for a guaranteed SUCCEEDED (or the existing REQ-13 fail-loud path) instead of a TIMED-OUT.

New regression tests (tests/test_main.py, 6 new):

test_listen_budget_clips_to_platform_deadline_when_shorter_than_ requested_window

test_listen_budget_deadline_never_negative_even_ when_already_overdue

test_listen_budget_ignores_deadline_when_none_ local_run

test_listen_budget_prefers_requested_window_when_deadline_ is_generous

test_seconds_until_deadline_none_when_no_platform_ timeout

, test_seconds_until_deadline_computes_remaining_seconds — all six verified to fail against the pre-fix source (missing _seconds_until_deadline / deadline_remaining_s kwarg entirely) before the fix, and pass after.

Honest scope caveat: this closes a real, previously-unaudited gap and is architecturally the best explanation found for a TIMED-OUT that survives every static wall-clock cap already in place — but the account's monthly usage hard limit (resets 2026-08-15) blocks any cloud run this session, so it is not proven against a live caller-timeout-override run. Local apify run against tests/fixtures/input.qa.json confirms the happy path (no platform timeout env var set locally) is unaffected: resolved in <1s, connected, subscribed, ran the full 30s window, exited 0 with the expected "captured 0 messages" status. Needs a cloud QA run once the cap resets, ideally one that explicitly passes a short timeout query param on POST /v2/acts/.../runs alongside a much larger maxDurationSeconds in the body, to directly exercise the clipped path end-to-end (not just unit-tested).
Unrelated, pre-existing finding (not touched — out of scope for a TIMED-OUT fix): tests/test_input_schema.py::test_pay_per_event_declared fails on main too (actor-start priced $0.002 in .actor/pay_per_event.json vs. the fleet's $0.05 flat-fee standard the test expects) — looks like this Actor was missed by the recent fleet-wide $0.05 start-fee repricing pass. Flagging for a separate, dedicated pricing fix (repricing has its own 14-day-notice constraint — not safe to bundle into this change).

0.9 — 2026-08-12

Daily report flagged 17% 30-day success rate (28/34 runs failed, mostly TIMED-OUT). Could not read the failing customer runs directly (own-run API scope only ever shows this Actor's own 3 runs — none TIMED-OUT — the documented pattern: recent_failures was empty). Cloud runs/pushes were also blocked today by the account's monthly usage hard limit, so this fix is diagnosed from live log-reading via GET-only REST calls plus local reproduction, not a fresh cloud run.
Per the fleet fault-isolation pattern (
```
reference-fleet-fault-isolation- pattern
```
— the #1 cause of low-success actors fleet-wide, and the exact bug class v0.8 already partially closed for this Actor), re-audited src/parser.py::build_row and src/ws_client.py::_route_frame for any remaining "one bad message crashes the whole run" gap and found two, both reproduced locally before fixing:
1. build_row — non-dict sender / sender.identity.
  sender = inner.get("sender") or {}
  and the subsequent _badge_types(sender) call ran before the function's own try/except, so a payload where Kick sends sender (or sender.identity) as something other than an object (e.g. a bare string) raised an uncaught AttributeError — directly contradicting build_row's documented "never raises" contract, and would have crashed every subscribed channel's stream on one malformed message. Fix: new _as_dict() helper coerces sender and identity to {} on any non-dict shape before they're used, eliminating the crash instead of merely catching it after the fact; AttributeError also added to the existing defense-in-depth except clause around ResultRow(...) construction.
2. _route_frame — non-string data field.
  json.loads(frame.get ("data") or "{}")
  only caught json.JSONDecodeError. Pusher's protocol normally encodes data as a JSON string (documented at the top of ws_client.py), but a frame where data arrives already decoded (a dict) raises TypeError on json.loads, uncaught, crashing the whole run identically. Also hardened the mirror case — a data string that decodes to a non-object (e.g. a JSON array) — which would otherwise pass a non-dict inner payload downstream into build_row, itself an AttributeError risk. Both cases now log a warning and skip the one frame; chat_frames_seen still increments so the existing "chat arrived but nothing parsed" fail-loud path (v0.8) stays correct.
Customer-visible effect: a single malformed/reshaped chat message from Kick no longer has any code path that can crash the entire run for every subscribed channel — it's logged and skipped, matching every other malformed-payload path already hardened in this Actor (v0.8's non-numeric-chatroom_id fix, this release's two siblings).
New regression tests: test_build_row_survives_non_dict_sender_in_payload, test_build_row_survives_non_dict_identity_in_payload (test_parser.py); test_route_frame_survives_non_string_data_field, test_route_frame_survives_data_decoding_to_non_object (test_ws_client.py) — all four verified to fail against the pre-fix source and pass against the fix.
Scope note: this closes a genuine, reproducible fault-isolation gap, but the dominant failure status in the 30-day window is TIMED-OUT (platform-forced kill), not FAILED — an uncaught exception like the ones fixed here produces a fast FAILED exit, not a TIMED-OUT hang. This fix is therefore very likely a real but partial contributor; the TIMED-OUT majority may still trace to a cause outside this Actor's own wall-clock budgeting (all internal caps — RESOLVE_PHASE_MAX_S, RECV_CHUNK_S, SEND_TIMEOUT_S, DURATION_MAX_S — were re-verified correct and bound total wall-clock to ≤3540s against a 3660s platform timeout). See CHANGELOG entry discipline in
```
docs/specs/kick-chat- archive/notes.md
```
for the full trail of prior TIMED-OUT investigations on this Actor (v0.4–v0.8) — none reproduced a live bug from this session's evidence gathering. Flagged for cloud QA + a fresh customer- facing check once the account's usage hard limit resets (2026-08-15).

0.8 — 2026-08-06

Daily report re-flagged 16% 30-day success rate (29/37 TIMED-OUT, 37 total). Live-verified this is the same stale 30-day-window snapshot already diagnosed on 2026-08-05: publicActorRunStats30Days is byte-identical to the pre-v0.7-push reading (
```
TIMED-OUT: 29, SUCCEEDED: 6, FAILED: 1, ABORTED: 1, TOTAL: 37
```
), the live build is already 0.7.1 (finished 2026-08-05T07:54:31Z, contains the send-timeout hang fix), and our own last run (RH4CPSPeJop6wzq8H) SUCCEEDED that same day. Zero customer runs have landed in the ~24h since — traffic on this Actor is very low (users_30d historically 1-2) — so the trailing window hasn't moved at all. Not a new TIMED-OUT bug; the wall-clock-budget class (REQ: resolve-phase cap, listen-phase cap below platform timeoutSecs, recv/send chunk timeouts) was already fully addressed across v0.4-v0.7 and re-confirmed live and correct today (
```
defaultRunOptions.timeoutSecs = 3660s
```
on the platform vs. DURATION_MAX_S = 3540s in code).
Per this task's explicit brief, independently applied the two other fleet fault-isolation requirements regardless of the TIMED-OUT verdict:
1. Fault isolation (src/parser.py::build_row) — found and fixed a real, previously-uncaught bug: a malformed (non-numeric) chatroom_id field inside one incoming ChatMessageEvent payload raised an unhandled ValueError (from int(...)) that propagated out of build_row, through _stream_and_archive's async generator, and would have crashed the ENTIRE run for every subscribed channel — not just skipped the one bad message. Reproduced locally before fixing. Fix: _int_or_default() coerces safely (falls back to the already-known chatroom_id), and the whole ResultRow(...) construction is wrapped in
  try/except (ValidationError, ValueError, TypeError)
  as defense-in-depth, matching build_row's own documented "skip, don't crash" contract for malformed payloads.
2. Never a silent empty success — added ListenStats.chat_frames_seen (src/ws_client.py), incremented whenever a ChatMessageEvent frame for a chatroom we subscribed to is identified (regardless of parse outcome). main.py now distinguishes a genuinely quiet/offline channel (chat_frames_seen == 0 — REQ-13's existing valid-empty- success path, unchanged) from chat activity that arrived but 100% failed to parse (chat_frames_seen > 0, kept == 0 — most likely Kick changed its payload shape): the new case dumps up to 5 raw failed payloads to the KVS (RAW_PAYLOAD_SAMPLES key) via Actor.set_value and fails loud (SystemExit(1)) with a clear status message instead of silently reporting "0 messages captured."
New regression tests: test_build_row_survives_non_numeric_chatroom_id_in_payload, test_build_row_catches_unexpected_row_construction_failure (test_parser.py); test_route_frame_increments_chat_frames_seen_* x3 (test_ws_client.py); test_should_fail_on_silent_parse_failure_* x3, test_stream_and_archive_captures_raw_samples_on_parse_failure, test_stream_and_archive_caps_raw_samples_at_max, test_fail_on_silent_parse_failure_dumps_kvs_and_exits (test_main.py).

0.7 — 2026-08-05

Daily report flagged 16% 30-day success rate (29/37 TIMED-OUT). Triage confirmed the TIMED-OUT count (29) has been flat across three checks spanning 18 days (2026-07-18, 2026-07-20, 2026-08-05) while total runs and successes both grew — the v0.6 (2026-07-10) resolve-phase fix is holding; every run since is a legacy pre-fix TIMED-OUT sitting in the 30-day trailing window, expected to fully age out ~2026-08-09. Not a new active bug. See docs/specs/kick-chat-archive/notes.md.
Independent code audit for any remaining unbounded-hang vector (the brief for this fix asked for one) found a real, if narrower, gap: ws_client.py's ws.send() calls (subscribe frames in _send_subscriptions, the ping->pong reply in _handle_control_frame) had no timeout at all — the mirror-image of the RECV_CHUNK_S hang fixed in v0.5, just on the write path. A congested proxy or a peer that stops reading (no RST/FIN) would leave any of these
```
await ws.send(...)
```
calls blocked forever, invisible to the existing RECV_CHUNK_S / RESOLVE_PHASE_MAX_S / DURATION_MAX_S caps because none of them bound writes.
Fix: _send_with_timeout() wraps every ws.send() in asyncio.wait_for(..., timeout=SEND_TIMEOUT_S=10.0) and raises ConnectionStalledError on a stall. _send_subscriptions stops at the first stalled chatroom rather than retrying the remaining ones against a dead pipe (bounds total subscribe-phase stall cost to one SEND_TIMEOUT_S, not channel_count * SEND_TIMEOUT_S). The listen loop (listen(), _iter_messages()) treats ConnectionStalledError the same as websockets.ConnectionClosed — log + clean early return — so a stalled write now produces a fast, bounded exit (existing REQ-13 fail-loud path fires when zero subscriptions succeeded) instead of an unbounded hang.
Added tests/test_ws_client.py (6 tests) — locks in the stall-detection behavior on both the subscribe path and the ping/pong path, plus the happy-path pass-through.

0.6 — 2026-07-10

Fix the actual TIMED-OUT root cause behind the "Under maintenance" flag (30-day customer success rate 9%, 29/33 runs TIMED-OUT). Build 0.5.1's RECV_CHUNK_S fix addressed a different hang vector inside the WebSocket listen loop and was already live, but customer runs kept TIMED-OUT — because the real bug is upstream of the listen loop entirely.
Root cause: _resolve_all (REST slug -> chatroom_id lookup, up to 20 channels x 4 retries x 30s HTTP timeout + exponential backoff each in api_client.py) had no wall-clock budget of its own, and the time it took was never subtracted from the WebSocket listen window (max_duration_seconds). A customer with several slow/rate-limited slugs (routine on Apify's shared proxy IPs hitting Kick's Cloudflare-protected REST API) could burn most or all of the run's time budget just resolving channels — before listening even started — pushing total wall-clock past the platform's timeoutSecs=3660 buffer and getting killed as TIMED-OUT instead of exiting cleanly via the Actor's own duration cap. Single-slug, low-latency local QA (the existing tests/fixtures/input.qa.json) resolves in well under a second and never exercised this path.
Fix: cap the resolve phase at RESOLVE_PHASE_MAX_S=90s wall-clock (src/main.py::_resolve_all, _resolve_into) — proceeds with whatever channels resolved in time rather than blocking indefinitely — and deduct the resolve phase's actual elapsed time from the WebSocket listen budget (compute_listen_budget_s) so total Actor wall-clock (resolve + listen) never exceeds the customer's own maxDurationSeconds, regardless of how long resolution took.
README: corrected maxDurationSeconds doc from "5–3,600 seconds" to the actual enforced range "5–3,540 seconds (59 min)" — the stated ceiling didn't match DURATION_MAX_S in src/models.py, which may have nudged customers toward duration values close to the platform timeout with no headroom.

0.5 — 2026-06-13

Add RECV_CHUNK_S=45 cap on each ws.recv() call in _iter_messages. Previously the recv timeout was set to the full remaining window duration (up to 3540 s). In cloud environments where NAT/firewall infrastructure silently drops idle TCP connections (no RST/FIN), the recv would hang until the window expired rather than detecting the dead connection quickly. With the 45-second chunk cap, a stale TCP connection is detected within one chunk window; a chunk timeout on a still-live connection is benign (the loop continues for another chunk). This closes a residual hang vector on channels with no chat activity.

0.4 — 2026-06-09

Fix 10/13 TIMED-OUT customer runs. Root cause: maxDurationSeconds cap (3600 s) matched the Apify platform timeoutSecs exactly, so the platform timer raced the Actor's listen window during container startup (~5-10 s overhead) and won → the run reported TIMED-OUT instead of SUCCEEDED. Fix: reduce DURATION_MAX_S to 3540 s (59 min) and set the platform defaultRunOptions.timeoutSecs to 3660 s (60 s buffer over the new cap).
Replace asyncio.get_event_loop() with asyncio.get_running_loop() in ws_client.py (Python 3.10+ best practice; get_event_loop() is deprecated when called outside a running event loop context).
Add ping_interval=None to websockets.connect() to disable library-level WebSocket pings. Pusher drives its own heartbeat via pusher:ping / pusher:pong at the application layer; the library's concurrent ping occasionally interfered in cloud environments causing spurious ConnectionClosed during quiet channels.

0.3 — 2026-06-01

Fix "Under maintenance" flag. A run that connected to Kick's chat socket and subscribed successfully but saw zero messages (every channel offline/silent for the window) used to exit 1 — so Apify's automated daily QA, which prefills a single channel that is often offline, failed three days running and unlisted the Actor.
A clean connect + subscribe with zero messages is now a successful empty run (exit 0) with an explanatory status message. Fail-loud (exit 1) is reserved for a genuinely broken integration: the socket never connects, or no channel accepts the subscription (ListenStats.connected / subscriptions_succeeded).

0.1.0 — 2026-05-16

Initial release. Subscribes to Kick.com chat via the public Pusher WebSocket, archives one row per chat message until the duration or message-count cap fires. Real-time only — Kick exposes no historical chat retrieval.

Kick Data Scraper

aitooolsmax/kick-data-scraper

Discover Kick channels and get clean channel snapshots from search, category browsing, livestream discovery, or direct slugs.

AI Tools Max

Kick Channel Scraper

fernand099/kick-scraper

Scrape real-time data from Kick.com channels. Search by keywords to get live viewer counts, stream titles, categories, durations, and channel bios. Perfect for trending analysis, content creation, and market research. Fast, clean JSON and CSV output.

ClickRun

Kick Scraper

solidcode/kick-scraper

[💰 $2.5 / 1K] Scrape Kick.com channels, live streams, videos, clips, and top-channel rankings. Get profiles, followers, viewer counts, stream titles, categories, social links, and more — for any channel or category.

SolidCode

Kick.com Streamer & Channel Analytics

zhorex/kick-scraper

Extract streamer profiles, live streams, VODs, clips, and channel rankings from Kick.com. No API key, no proxy, no browser needed. 4 modes in one actor.

Sami

Kick Video Downloader ✅ | No proxy needed

x_guru/kick-video-downloader

Download Kick.com videos, VODs, clips and streams. No proxy needed. Save to Apify storage or your own cloud (AWS S3, Azure, Google Cloud).

Hundevmode Labs

229

Kick Video Downloader

parsebird/kick-video-downloader

Download Kick.com videos, VODs, and clips in up to 1080p60 quality. Save Kick stream recordings, highlights, and clips to Apify storage. No proxy needed. Export download links via API. Supports batch downloads.

ParseBird

643

TeePublic Scraper 👕

easyapi/teepublic-scraper

Scrape product listings from TeePublic.com including design details, pricing, images and more. Perfect for market research, price monitoring and product analysis.

EasyApi

5.0

TikTok Profile Scraper — Emails, Followers & Commenters

afanasenko/tiktok-profile-scraper

Scrape TikTok profile data at scale — followers and following lists, video commenters, and username enrichment. Every profile returns emails, bio links, follower and like counts, and video stats. No login needed. Export to CSV, JSON or Excel, or run via API.

Andrey Afanasenko

212

TikTok User Search Scraper - Find Creators [NO LOGIN] ✅

unseenuser/tiktok-user-search-scraper

Search TikTok users and creators by keyword. Get handles, bios, follower counts, and recent videos. Built for creator discovery, influencer research, and lead generation by topic or niche. No login, no cookies. Pair with our Followers Scraper to map full audiences.

Unseen User

5.0

Social Media Influencer Scraper

easyapi/social-media-influencer-scraper

Discover top influencers across TikTok, Instagram, and YouTube with ease. Get detailed metrics, recent posts, and engagement data for your influencer marketing campaigns. Perfect for brands, marketers, and researchers looking to tap into social media trends.

EasyApi

690

1.1

Kick Chat Scraper & Real-Time Archive

Kick.com Chat Archive — Changelog

0.11 — 2026-08-17

0.10 — 2026-08-13

0.9 — 2026-08-12

0.8 — 2026-08-06

0.7 — 2026-08-05

0.6 — 2026-07-10

0.5 — 2026-06-13

0.4 — 2026-06-09

0.3 — 2026-06-01

0.1.0 — 2026-05-16

You might also like

Kick Data Scraper

Kick Channel Scraper

Kick Scraper

Kick.com Streamer & Channel Analytics

Kick Video Downloader ✅ | No proxy needed

Kick Video Downloader

TeePublic Scraper 👕

TikTok Profile Scraper — Emails, Followers & Commenters

TikTok User Search Scraper - Find Creators [NO LOGIN] ✅

Social Media Influencer Scraper

Kick.com Chat Archive — Changelog

0.11 — 2026-08-17

0.10 — 2026-08-13

0.9 — 2026-08-12

0.8 — 2026-08-06

0.7 — 2026-08-05

0.6 — 2026-07-10

0.5 — 2026-06-13

0.4 — 2026-06-09

0.3 — 2026-06-01

0.1.0 — 2026-05-16