DEV Community: KazKN

Turn a Zalo Export into Clean pandas DataFrames

KazKN — Sun, 09 Aug 2026 16:23:26 +0000

Zalo export records do not belong in one flat table. A group is not a member, a
member is not a profile, and a message is not a conversation summary. Flattening
all five record types into one spreadsheet creates duplicate columns and hides
the relationships your analysis needs.

This tutorial retrieves an Apify Dataset, builds one pandas DataFrame per record
type, joins group members to visible profiles, and writes a multi-sheet Excel
workbook.

Disclosure: I built the Zalo Data Exporter used below. I may earn revenue
from Apify when the Actor is run through links in this article, at no extra
cost to you.

Install the data tools

pip install apify-client pandas openpyxl

Keep the Apify token outside the notebook or script:

export APIFY_API_TOKEN="your-token-from-apify-console"

The first connection for a saved account alias still requires a temporary QR
approval in Apify Console. Once connected, later calls can reuse the encrypted
login while the session remains valid.

Open the Zalo Data Exporter

Retrieve the Dataset

Start with a bounded group roster:

import os

import pandas as pd
from apify_client import ApifyClient


client = ApifyClient(os.environ["APIFY_API_TOKEN"])

run = client.actor("kazkn/zalo-member-profile-exporter").call(
    run_input={
        "exportMode": "groupRoster",
        "accountAlias": "main",
        "maxGroups": 1,
        "maxMembersPerGroup": 100,
    }
)

records = client.dataset(run["defaultDatasetId"]).list_items().items
print(f"Dataset records: {len(records)}")

The result can contain profile, group, groupMember, conversation, and
message rows. The selected preset determines which families appear.

Build one DataFrame per record type

record_types = (
    "profile",
    "group",
    "groupMember",
    "conversation",
    "message",
)

frames = {
    record_type: pd.DataFrame(
        record for record in records
        if record.get("recordType") == record_type
    )
    for record_type in record_types
}

for record_type, frame in frames.items():
    print(f"{record_type}: {len(frame)} rows")

An empty DataFrame is expected when the preset did not request that record
family. Do not treat it as an extraction error without checking the chosen
preset and the run summary.

Preserve IDs as strings

Spreadsheet tools sometimes convert long identifiers into floating-point
numbers or scientific notation. Cast identifiers before saving:

id_columns = {
    "profile": ["userId"],
    "group": ["groupId"],
    "groupMember": ["groupId", "userId"],
    "conversation": ["conversationId"],
    "message": ["messageId", "threadId", "senderId"],
}

for record_type, columns in id_columns.items():
    frame = frames[record_type]
    for column in columns:
        if column in frame.columns:
            frame[column] = frame[column].astype("string")

Missing values remain nullable strings. That matters for profile data because
Zalo does not expose every field for every visible account.

Join group members to visible profiles

The groupMember table keeps group membership. The profile table holds
profile fields that were visible during the run. Join them on userId without
dropping members that have no profile row.

members = frames["groupMember"].copy()
profiles = frames["profile"].copy()

profile_columns = [
    column for column in (
        "userId",
        "zaloName",
        "avatarUrl",
        "relationship",
    )
    if column in profiles.columns
]

if not members.empty and "userId" in members.columns:
    enriched_members = members.merge(
        profiles[profile_columns],
        on="userId",
        how="left",
        suffixes=("", "_profile"),
        validate="many_to_one",
    )
else:
    enriched_members = members

The left join is deliberate. A member row proves visible membership in a joined
group. A missing profile field only means that the field was not returned in
that run.

Keep completeness with the analytical table

Group and conversation records can carry status fields explaining truncation or
the boundary reached by the read. Preserve those fields in any table used for
reporting.

For chat analysis, inspect conversation rows before counting messages:

conversations = frames["conversation"]

status_columns = [
    column for column in (
        "conversationId",
        "title",
        "completeness",
        "terminationReason",
    )
    if column in conversations.columns
]

conversation_status = conversations[status_columns].copy()

A conversation that stopped at PARTIAL_LIMIT should not be reported as a full
history. The configured message count, date boundary, Zalo Web response, or a
safety ceiling can stop the read.

Write separate Excel sheets

sheet_frames = {
    "Group members": enriched_members,
    "Groups": frames["group"],
    "Profiles": frames["profile"],
    "Conversations": frames["conversation"],
    "Messages": frames["message"],
}

with pd.ExcelWriter("zalo-export.xlsx", engine="openpyxl") as writer:
    for sheet_name, frame in sheet_frames.items():
        if not frame.empty:
            frame.to_excel(writer, sheet_name=sheet_name, index=False)

This layout is easier to audit than one wide sheet. It also maps directly to
the focused Dataset views exposed by the Actor.

Add a small validation report

Before sending the workbook to another team, record the row counts and duplicate
checks:

validation = []

for record_type, frame in frames.items():
    validation.append({
        "recordType": record_type,
        "rows": len(frame),
        "columns": len(frame.columns),
    })

if "recordKey" in enriched_members.columns:
    duplicate_member_keys = int(
        enriched_members["recordKey"].duplicated().sum()
    )
else:
    duplicate_member_keys = 0

print(pd.DataFrame(validation))
print("Duplicate group-member record keys:", duplicate_member_keys)

The validation output does not prove universal completeness. It tells you what
this bounded run delivered and whether your local transformation introduced
obvious duplicates.

Data pipeline rules that prevent bad reports

Keep recordType in the raw landing table.
Preserve identifier columns as strings.
Use left joins when enriching membership rows.
Carry completeness and termination fields into chat reports.
Store the source run ID and collection time with each delivery.
Never infer phone numbers or hidden profile fields from missing values.

The useful output is not simply an Excel file. It is a set of typed tables whose
relationships and limits remain visible after the export leaves Apify.

👉 Create a bounded Zalo Dataset for pandas

A Repeatable Zalo Data Export Workflow for Agencies

KazKN — Sun, 09 Aug 2026 16:22:52 +0000

An agency handoff fails when the client receives a spreadsheet with no source,
no limits, and no way to reproduce it. Zalo work adds another constraint: the
data belongs to the account the client connects, and the first connection needs
a QR approval.

The workflow below turns that constraint into a clear operating procedure. It
is built for agencies and automation teams supporting sales, CRM, community,
or data operations in Vietnam.

Disclosure: I built the Zalo Data Exporter used in this workflow. I may
earn revenue from Apify when the Actor is run through links in this article,
at no extra cost to you.

Start with the deliverable

Do not begin by asking for every available Zalo record. Pick the file the client
will use.

Client job	Actor preset	Delivery
Reconcile a joined-group roster	`groupRoster`	Groups, visible members, linked profiles
Prepare visible contacts for CRM	`contactsAndProfiles`	Profile and relationship rows
Preserve accessible business chats	`conversationBackup`	Conversation summaries and message rows
Build a bounded internal snapshot	`completeSnapshot`	All visible record families

For a new engagement, groupRoster is usually the easiest proof. One group and
100 visible members produce a result the client can check without launching a
large account-wide job.

Open the Zalo Data Exporter

Assign one alias to one Zalo account

The Actor saves an encrypted login under accountAlias. The alias is scoped to
the Apify user, but it still needs a simple naming rule inside an agency account.

Use names that identify the operational connection without exposing a phone
number or secret:

{
  "accountAlias": "client-acme-vn",
  "exportMode": "groupRoster",
  "maxGroups": 1,
  "maxMembersPerGroup": 100
}

If a second client connects another Zalo account, give it another alias. Do not
reuse an alias to switch accounts. Refresh the same alias only when the same
connected account needs a new login.

Put the QR step in the onboarding call

The first connection is not an unattended background task. Schedule it as part
of onboarding:

Open the small starter run in Apify Console.
Ask the account owner to scan the temporary QR in Zalo.
Keep the run open until the Dataset appears.
Confirm the account alias and the returned record types.

The QR expires quickly, so the account owner should be ready before the run
starts. The QR record is removed after success, rejection, or expiry. Later
runs can reuse the encrypted saved login while Zalo accepts the session.

Define limits in the statement of work

Record limits are part of the deliverable, not hidden technical settings. Write
them into the project scope.

Example group-roster scope:

{
  "exportMode": "groupRoster",
  "accountAlias": "client-acme-vn",
  "maxGroups": 3,
  "maxMembersPerGroup": 250
}

Example chat scope:

{
  "exportMode": "conversationBackup",
  "accountAlias": "client-acme-vn",
  "messagesSince": "2026-07-01",
  "maxConversations": 3,
  "maxMessagesPerConversation": 200,
  "includeMessageText": true,
  "includeAttachmentMetadata": true
}

The limits control runtime, output volume, and the possible Actor charge. They
also make acceptance testing possible. A client can verify three requested
conversations more easily than an undefined request for the entire account.

Deliver typed views, not one flattened mystery file

The Dataset contains five possible recordType values:

profile
group
groupMember
conversation
message

Apify provides focused views for each family. Keep recordType in raw CSV or
JSON exports so the client can reconstruct the source model.

For spreadsheet delivery, a practical package is:

delivery/
  groups.csv
  group-members.csv
  profiles.csv
  run-summary.txt

The run summary should state the account alias, collection time, configured
limits, returned counts, and any partial conversation status. Never turn a
partial read into a silent success claim.

Connect the Dataset to the client stack

Developers can retrieve the result with ApifyClient:

import os
from apify_client import ApifyClient


client = ApifyClient(os.environ["APIFY_API_TOKEN"])
run = client.actor("kazkn/zalo-member-profile-exporter").call(
    run_input={
        "exportMode": "groupRoster",
        "accountAlias": "client-acme-vn",
        "maxGroups": 3,
        "maxMembersPerGroup": 250,
    }
)

items = client.dataset(run["defaultDatasetId"]).list_items().items

From there, send group-member rows to a CRM staging table, save profiles to a
warehouse, or publish a controlled spreadsheet. The client remains responsible
for deciding which exported fields belong in each downstream system.

Set support expectations before the first run

Three cases deserve explicit wording in the handoff:

A new or expired session needs another QR approval.
The Actor returns only data visible to the connected account.
Zalo can change its private web behavior, challenge a session, or stop a history read at a platform boundary.

The Actor does not recover deleted messages, discover hidden members, join
groups, or send messages. An agency should reject those requirements instead of
burying them in a generic scraping promise.

Agency delivery checklist

One saved alias per connected Zalo account.
One small proof run before increasing limits.
A named preset and explicit record cap in the project scope.
Separate Dataset views plus the run summary.
A documented QR refresh contact on the client side.
No Apify token, QR image, or session material in the delivery folder.

This setup gives the client a reproducible export and gives the agency a support
boundary it can explain before the first invoice.

👉 Run the agency starter export on Apify

How to Run a Zalo Data Export from Python with the Apify API

KazKN — Sun, 09 Aug 2026 16:21:23 +0000

A useful Zalo export should end as records your code can process. For a group
roster, that means separate group, member, and profile rows with stable IDs. For
a chat backup, it means conversation summaries and message rows with explicit
limits.

This guide runs a bounded export with Python, retrieves the Apify Dataset, and
splits the result by recordType.

Disclosure: I built the Zalo Data Exporter used below. I may earn revenue
from Apify when the Actor is run through links in this article, at no extra
cost to you.

The first connection is interactive

The Actor connects to your own Zalo account. It does not scrape anonymous or
hidden account data.

Your first run for an account alias requires a temporary QR:

Start a small run in the Apify Console.
Open Output and select First run: scan this Zalo QR.
Scan and approve the QR in the Zalo mobile app.
Wait for the Dataset to appear.

The QR expires after roughly 100 seconds. Once the connection succeeds, later
runs under the same Apify user and accountAlias can reuse the encrypted saved
login while it remains valid.

Open the Zalo Data Exporter

Install the Python client

Create a virtual environment if your project does not already have one, then
install the client:

pip install apify-client

Load the Apify token from an environment variable. Do not put it in the script
or paste it into a public prompt.

export APIFY_API_TOKEN="your-token-from-apify-console"

Run a bounded group roster export

The starter input asks for one joined group and at most 100 visible members.
Those limits keep the first automated call easy to inspect.

import os

from apify_client import ApifyClient


client = ApifyClient(os.environ["APIFY_API_TOKEN"])

run_input = {
    "exportMode": "groupRoster",
    "accountAlias": "main",
    "maxGroups": 1,
    "maxMembersPerGroup": 100,
}

run = client.actor("kazkn/zalo-member-profile-exporter").call(
    run_input=run_input,
)

items = client.dataset(run["defaultDatasetId"]).list_items().items
print(f"Received {len(items)} records")

The Actor writes a normalized Dataset. A single run can contain several record
families, so keep recordType when you store or transform the data.

from collections import Counter


counts = Counter(item.get("recordType") for item in items)
for record_type, count in sorted(counts.items()):
    print(record_type, count)

A group roster can return group, groupMember, and profile records. A
conversation backup can return conversation and message records.

Select the records your job needs

Filtering locally is straightforward:

members = [
    item for item in items
    if item.get("recordType") == "groupMember"
]

profiles = {
    item["userId"]: item
    for item in items
    if item.get("recordType") == "profile" and item.get("userId")
}

member_rows = []
for member in members:
    profile = profiles.get(member.get("userId"), {})
    member_rows.append({
        "groupId": member.get("groupId"),
        "userId": member.get("userId"),
        "displayName": member.get("displayName"),
        "zaloName": profile.get("zaloName"),
        "avatarUrl": profile.get("avatarUrl"),
    })

Profile fields are nullable because Zalo does not expose every field for every
visible member. Keep the member row even when its linked profile is incomplete.

Switch to another export preset

The same API call supports four outcomes:

Job	`exportMode`	Main record types
Joined-group roster	`groupRoster`	`group`, `groupMember`, `profile`
Visible contacts	`contactsAndProfiles`	`profile`
Accessible chat backup	`conversationBackup`	`conversation`, `message`
Visible-account snapshot	`completeSnapshot`	All five record types

A bounded conversation export looks like this:

run_input = {
    "exportMode": "conversationBackup",
    "accountAlias": "main",
    "messagesSince": "2026-07-01",
    "maxConversations": 3,
    "maxMessagesPerConversation": 200,
    "includeMessageText": True,
    "includeAttachmentMetadata": True,
}

Conversation records report whether the read reached the start returned by
Zalo Web, stopped at your limit, or hit another bounded platform condition. Do
not label a partial conversation as a complete archive.

Handle reconnects without breaking the workflow

If the saved login expires, the run can ask for another QR. Set
reconnectZalo to true for one refresh run and approve the new QR in the
Console. Keep the same alias when refreshing the same Zalo account.

Use a different alias for a different Zalo account:

run_input["accountAlias"] = "client-vietnam-02"

The first call for that alias will require its own QR approval.

Production checklist

Start with explicit record limits.
Keep recordType, stable IDs, and completeness fields.
Store the Apify token in an environment variable.
Expect a manual QR step for a new or expired saved login.
Use one account alias per connected Zalo account.
Retry only after reading the public error code and run status.

The API automates the repeatable part of the workflow. Authentication remains
attached to the account owner, and the Dataset only contains data visible to
that connected account.

👉 Run a bounded Zalo export from Python

Zalo Chat Backup: Export Messages and Contacts to JSON or CSV

KazKN — Sun, 09 Aug 2026 01:22:25 +0000

A backup that only restores inside an app is useful when you change phones. It
is much less useful when you need to search conversations, audit a date range,
prepare contact data, or feed a Dataset into Python.

For those jobs, the important question is not “Can I copy my Zalo account?” It
is: Which visible records do I need, and how do I export them with explicit
limits?

This guide covers four practical workflows: chat backup, contact export, group
roster, and a complete visible-account snapshot.

Disclosure: I built the Zalo Data Exporter used in this guide. If you sign
up or run it through links in this article, I may earn revenue from Apify at
no additional cost to you.

Choose one outcome, not every data type

Goal	Preset	Main Dataset views
Back up accessible messages	`conversationBackup`	Conversations, Messages
Export visible contacts	`contactsAndProfiles`	Contacts and profiles
Export members from joined groups	`groupRoster`	Groups, Group members, Profiles
Create one bounded visible-data snapshot	`completeSnapshot`	All five record types

Starting with one preset makes the first result faster to inspect and cheaper to
bound. A complete snapshot is useful only when you genuinely need all record
families together.

How authentication works

The first run generates a temporary QR in that run's Output. You scan and
approve it with the Zalo mobile app. After successful authentication, the Actor
stores an encrypted session separated by Apify user and accountAlias.

Later runs can reconnect automatically. A QR may still be required after
expiry, revocation, or a Zalo challenge. This is why “one QR forever” would be
the wrong promise.

Workflow 1: back up accessible conversations

Open Zalo Data Exporter
and choose 💬 Conversation backup.

Use a date and message limit that match the question you are trying to answer:

{
  "exportMode": "conversationBackup",
  "accountAlias": "main",
  "messagesSince": "2026-07-01",
  "maxConversations": 3,
  "maxMessagesPerConversation": 200,
  "includeMessageText": true,
  "includeAttachmentMetadata": true
}

The unified Dataset returns conversation and message rows. Each conversation
includes a completeness status:

COMPLETE_TO_ZALO_WEB_START — Zalo returned the real start available on Zalo Web;
PARTIAL_LIMIT — your date or message limit stopped the read;
PARTIAL_ZALO_BOUNDARY — Zalo or a safety boundary stopped it first;
FAILED — no safe history result was returned for that conversation.

This distinction matters. “The run succeeded” and “every conversation is
complete” are not the same statement.

Workflow 2: export contacts for a spreadsheet or CRM

Choose 👤 Contacts & profiles. The profile rows can include Zalo user ID,
display name, Zalo name, avatar URL, and relationship when those fields are
visible.

Use userId or recordKey as the stable key. Do not treat display names as
unique, and do not invent phone numbers or emails when Zalo leaves a field
empty.

Workflow 3: export joined-group members

Choose 👥 Group roster and start with one group and 100 members. The video
at the top demonstrates this workflow from QR to spreadsheet.

The Actor separates group, membership, and profile records so one person can
belong to multiple groups without corrupting your contact table.

Workflow 4: create a complete visible-account snapshot

Choose 📦 Complete visible-account snapshot only when your use case needs
contacts, profiles, groups, members, conversations, and messages together.

Set all limits explicitly. More record families mean more runtime, more Dataset
rows, and a higher possible charge.

Automate a bounded chat export with Python

Complete the first QR connection in the Apify Console, then call the saved
session from code:

import os
from apify_client import ApifyClient

client = ApifyClient(os.environ["APIFY_API_TOKEN"])

run = client.actor("kazkn/zalo-member-profile-exporter").call(run_input={
    "exportMode": "conversationBackup",
    "accountAlias": "main",
    "maxConversations": 3,
    "maxMessagesPerConversation": 200,
    "includeMessageText": True,
})

items = client.dataset(run["defaultDatasetId"]).list_items().items
conversations = [x for x in items if x.get("recordType") == "conversation"]
messages = [x for x in items if x.get("recordType") == "message"]

print({"conversations": len(conversations), "messages": len(messages)})

Keep APIFY_API_TOKEN in an environment variable. Never paste it into the
article, source code, or an AI assistant.

CSV, Excel, or JSON?

Choose based on the next step:

CSV for imports and simple pipelines;
Excel for filtering, manual review, and sharing with spreadsheet users;
JSON for APIs, nested metadata, and code;
Dataset API for scheduled or event-driven workflows.

The Output tab exposes focused views, while API users can filter the unified
Dataset on recordType.

Privacy and product boundaries

Zalo Data Exporter is read-only. It has no path for sending messages, adding
friends, or changing group membership. It does not bypass authentication,
recover deleted messages, discover unjoined groups, or access mobile-only
encrypted archives.

Zalo can change private behavior, invalidate sessions, or require another
verification. Start with a non-critical account, conservative limits, and an
appropriate retention policy for exported membership and message data.

FAQ

Can I back up all Zalo messages?

The Actor can export accessible direct and joined-group history within your
date, message, time, and platform boundaries. It does not promise universal or
deleted-message recovery.

Can later runs run without a QR?

They can reuse the encrypted session for the same Apify user and
accountAlias. A new QR is required when the saved login expires or is revoked.

What happens when a QR expires?

The run reports QR_EXPIRED. Start a new run and scan the new code; the old QR
is intentionally deleted and cannot be reused.

How is the Actor priced?

It uses pay-per-event pricing for the run start and delivered record types.
Prices vary with the Apify subscription. The Console shows the maximum possible
charge before launch, so explicit small limits are the safest first step.

Start with the smallest useful export

Choose one preset, keep the starter limits, inspect the Dataset views, and only
then increase scope.

👉 Run a bounded Zalo export on Apify

Apify links in this article support the Actor's developer. Results depend on
what the connected account can see and the limits you configure.

How to Export Zalo Group Members to CSV or Excel

KazKN — Sun, 09 Aug 2026 01:21:18 +0000

Copying a Zalo group roster by hand looks manageable until you have more than
one group. Then the workflow becomes scrolling, opening profiles, copying names,
removing duplicates, and trying to remember which row came from which group.

This guide shows a reproducible way to export the members your own Zalo account
can see in joined groups. The result is a structured Dataset you can download as
CSV, Excel, or JSON.

Disclosure: I built the Zalo Data Exporter used below. If you sign up or
run the Actor through links in this article, I may earn revenue from Apify at
no additional cost to you.

What the export does — and does not do

The Actor authenticates your own account with a temporary Zalo QR. It is a
read-only exporter, not an anonymous people finder.

It can return:

groups the connected account has joined;
members visible inside those groups;
linked profile fields Zalo exposes to that account;
separate Dataset views for groups, members, and profiles.

It does not discover hidden groups, invisible members, deleted messages, or a
public phone-number database.

The data model

Record type	Useful fields
`group`	`groupId`, name, visible member count
`groupMember`	`groupId`, `userId`, display name, stable record key
`profile`	Zalo user ID, display name, Zalo name, avatar URL, relationship

Keeping membership and profile rows separate matters. A person can belong to
multiple groups without requiring duplicate profile objects.

Step-by-step: export one group first

1. Open the Actor

Open Zalo Data Exporter on Apify
and keep the 👥 Group roster preset.

The public input uses outcome presets instead of low-level scopes. You do not
need to provide Zalo cookies, an IMEI, a proxy, or a session passphrase.

2. Use conservative starter limits

Start with one group and 100 members:

{
  "exportMode": "groupRoster",
  "accountAlias": "main",
  "maxGroups": 1,
  "maxMembersPerGroup": 100
}

This is large enough to verify the output while keeping runtime and maximum
charge easy to understand. Increase only the limit that your use case needs.

3. Scan the temporary QR

On the first connection:

Click Start.
Open the run's Output tab.
Open ① First run: scan this Zalo QR.
Scan and approve it in the Zalo mobile app.
Keep the run open until the Dataset appears.

The QR expires quickly. If the run reports QR_EXPIRED, start a new run and
scan the newly generated code. Later runs can reuse the encrypted session saved
under the same accountAlias.

4. Inspect focused views

Check Groups first to confirm the source. Then open Group members and,
when needed, Contacts and profiles. Focused views make the spreadsheet easier
to validate before download.

5. Export the result

CSV is convenient for database and CRM imports.
Excel is useful for filtering and manual review.
JSON preserves the record structure for code and APIs.

Run the same export with Python

Complete the interactive QR connection once in the Apify Console. Then reuse
the saved session programmatically:

import os
from apify_client import ApifyClient

client = ApifyClient(os.environ["APIFY_API_TOKEN"])

run = client.actor("kazkn/zalo-member-profile-exporter").call(run_input={
    "exportMode": "groupRoster",
    "accountAlias": "main",
    "maxGroups": 1,
    "maxMembersPerGroup": 100,
})

items = client.dataset(run["defaultDatasetId"]).list_items().items
members = [item for item in items if item.get("recordType") == "groupMember"]

print(f"Exported {len(members)} visible group-member rows")

Load the token from APIFY_API_TOKEN; never paste it into source code or an AI
prompt.

Export a specific joined group

If you need one group, make a small discovery run first and copy its ID from the
Groups view. Then provide it in the advanced groupIds field:

{
  "exportMode": "groupRoster",
  "groupIds": ["joined-group-id-from-your-dataset"],
  "maxMembersPerGroup": 500
}

Only use IDs returned for the connected account. An inaccessible or incorrect
ID cannot produce a roster.

Pricing and limits

Zalo Data Exporter uses pay-per-event pricing. The start event and each saved
profile, group, group-member, conversation, or message record have separate
prices. Apify displays the maximum possible charge before the run.

The exact cost depends on your Apify subscription and the visible records
delivered. Small starter limits are useful for both validation and cost control.

Common failures

The QR expired

Start a new run and scan the new QR immediately. An expired image cannot be
reused.

The saved login no longer works

Enable Refresh this saved login for that same account and scan a new QR. Use
a new accountAlias for a different Zalo account.

The Dataset is smaller than the group UI

The exporter can only save members Zalo exposes to the connected account and
within your run limits. Treat the Dataset as visible-account data, not a claim
of universal group completeness.

FAQ

Can I export Zalo group members without coding?

Yes. Choose Group roster, scan the first-run QR, and download the focused
Dataset view as CSV or Excel.

Do I need to scan a QR every time?

Not normally. The first connection is interactive; later runs can reuse the
encrypted saved session until Zalo invalidates or challenges it.

Does the export include phone numbers?

Only fields Zalo makes visible to the connected account can be returned. The
Actor does not provide or infer a phone-number database.

Try the bounded workflow

Watch the six-minute video above, then repeat it with one group and 100 members.
Validate the three focused views before increasing the limits.

👉 Export visible Zalo group members on Apify

Apify links in this article support the Actor's developer. Results depend on
the connected account's visibility and configured limits.

Cách xuất danh bạ Zalo ra Excel để làm sạch dữ liệu CRM

KazKN — Sun, 09 Aug 2026 01:20:03 +0000

Danh bạ Zalo hữu ích khi bạn đang ở trong ứng dụng. Nhưng khi cần kiểm tra bản
ghi trùng, chuẩn hóa tên, lưu một snapshot hoặc chuẩn bị dữ liệu cho CRM, bạn
cần một bảng có cột rõ ràng — không phải hàng trăm màn hình hồ sơ mở thủ công.

Bài này hướng dẫn cách xuất danh bạ và hồ sơ mà tài khoản Zalo của bạn nhìn
thấy thành CSV, Excel hoặc JSON, rồi làm sạch dữ liệu mà không biến trường
trống thành thông tin tưởng tượng.

Minh bạch: Tôi là nhà phát triển của Zalo Data Exporter. Nếu bạn đăng ký
hoặc chạy Actor qua liên kết trong bài, tôi có thể nhận doanh thu từ Apify mà
bạn không phải trả thêm.

Danh bạ trong ứng dụng chưa phải là dữ liệu CRM

CRM cần các bản ghi ổn định, có nguồn và có thể cập nhật. Một bảng xuất Zalo hữu
ích nên giữ:

ID người dùng Zalo;
tên hiển thị và tên Zalo khi có;
avatar URL khi hiển thị;
trạng thái quan hệ hoặc nguồn bản ghi;
recordKey để nhận biết bản ghi giữa các lần chạy.

Điều quan trọng là chấp nhận trường trống. Nếu Zalo không hiển thị số điện
thoại, email hoặc tên thật, bản xuất không nên tự đoán.

Chọn đúng workflow

Zalo Data Exporter có bốn preset. Với danh bạ, hãy chọn 👤 Contacts &
profiles. Không cần bật lịch sử chat hoặc danh sách nhóm nếu bạn chỉ muốn một
snapshot liên hệ.

Mở preset Contacts & profiles

Hướng dẫn từng bước

1. Cấu hình lần chạy đầu tiên

Input tối thiểu:

{
  "exportMode": "contactsAndProfiles",
  "accountAlias": "main"
}

Preset quyết định loại dữ liệu. accountAlias là tên phiên đăng nhập được mã
hóa. Nếu bạn kết nối một tài khoản Zalo khác, hãy dùng alias khác.

2. Kết nối bằng QR tạm thời

Bấm Start, mở Output, quét QR trong ứng dụng Zalo và phê duyệt. QR sẽ bị
xóa sau khi thành công, bị từ chối hoặc hết hạn. Những lần chạy sau có thể kết
nối lại tự động bằng phiên đã lưu.

3. Mở đúng Dataset view

Chọn Contacts and profiles. View này tập trung các trường hữu ích cho bảng
tính; Dataset thống nhất vẫn dùng recordType: "profile" để API có thể lọc.

4. Tải file

Chọn Excel nếu người xử lý tiếp theo làm việc trong bảng tính.
Chọn CSV cho import CRM hoặc xử lý hàng loạt.
Chọn JSON để giữ kiểu dữ liệu cho code và API.

Làm sạch bảng trước khi nhập CRM

Giữ khóa, không chỉ giữ tên

Hai người có thể có cùng tên hiển thị. Dùng userId hoặc recordKey làm khóa
chính; dùng tên để hiển thị.

Ghi nguồn của snapshot

Thêm các cột nội bộ như source = Zalo, exportedAt, và accountAlias. Khi dữ
liệu thay đổi, bạn sẽ biết lần xuất nào tạo ra bản ghi.

Không điền giả trường thiếu

Nếu số điện thoại không xuất hiện, giữ trống. Một CRM sạch với trường thiếu tốt
hơn một CRM đầy dữ liệu không kiểm chứng.

Xử lý người xuất hiện ở nhiều nguồn

Một người có thể nằm trong danh bạ và trong nhiều nhóm. Nếu bạn kết hợp preset
Contacts với Group roster, hãy tách bảng quan hệ nhóm khỏi bảng hồ sơ thay vì
xóa mọi dòng “trùng tên”.

Tự động hóa snapshot bằng Python

Sau lần xác thực QR đầu tiên:

import os
from apify_client import ApifyClient

client = ApifyClient(os.environ["APIFY_API_TOKEN"])
run = client.actor("kazkn/zalo-member-profile-exporter").call(run_input={
    "exportMode": "contactsAndProfiles",
    "accountAlias": "main",
})

rows = client.dataset(run["defaultDatasetId"]).list_items().items
profiles = [row for row in rows if row.get("recordType") == "profile"]
print(f"Snapshot contains {len(profiles)} visible profiles")

Bạn có thể chạy định kỳ trên Apify, gửi Dataset qua webhook hoặc tải CSV vào
quy trình hiện có. Hãy đặt giới hạn và lịch chạy phù hợp thay vì thu thập lại
liên tục mà không có mục tiêu.

Khi nào nên dùng Complete snapshot?

Chỉ dùng 📦 Complete visible-account snapshot nếu bạn thật sự cần danh bạ,
hồ sơ, nhóm, thành viên, cuộc trò chuyện và tin nhắn trong cùng một run. Nó tạo
nhiều loại bản ghi hơn, chạy lâu hơn và có thể tốn nhiều hơn.

Đối với một dự án CRM chỉ cần danh bạ, preset chuyên biệt đơn giản và dễ kiểm
tra hơn.

Giới hạn và quyền riêng tư

Actor chỉ đọc dữ liệu hiển thị cho tài khoản đã kết nối. Nó không tìm hồ sơ ẩn,
nhóm chưa tham gia, cơ sở dữ liệu số điện thoại hay tin nhắn đã xóa. Nó cũng
không gửi tin nhắn, kết bạn hoặc thay đổi nhóm.

Áp dụng thời hạn lưu trữ phù hợp, hạn chế quyền truy cập file xuất và chỉ giữ
những trường cần thiết cho mục tiêu của bạn.

FAQ

Có thể xuất danh bạ Zalo ra CSV không?

Có. Chọn Contacts & profiles, kết nối QR lần đầu, rồi tải view tương ứng dưới
dạng CSV.

File có luôn chứa số điện thoại không?

Không. Trường chỉ có giá trị khi Zalo hiển thị cho tài khoản. Công cụ không suy
đoán hoặc mua dữ liệu số điện thoại.

Có thể dùng file trong CRM không?

Có, sau khi bạn chọn khóa ổn định, chuẩn hóa cột và giữ trường thiếu ở trạng
thái trống. CSV là định dạng import phổ biến; JSON phù hợp hơn cho API.

Tạo snapshot danh bạ đầu tiên

👉 Xuất danh bạ Zalo hiển thị ra CSV, Excel hoặc JSON

Liên kết Apify trong bài hỗ trợ nhà phát triển của Actor. Kết quả phụ thuộc vào
dữ liệu tài khoản đã kết nối có thể nhìn thấy.

Cách quét thành viên nhóm Zalo và xuất danh sách ra Excel

KazKN — Sun, 09 Aug 2026 01:19:47 +0000

Bạn quản lý một cộng đồng Zalo và cần danh sách thành viên để đối chiếu, làm
báo cáo hoặc chuẩn bị dữ liệu CRM. Cách thủ công là mở từng nhóm, cuộn danh
sách, sao chép từng tên và ghép lại trong Excel. Với vài chục thành viên thì
được. Với nhiều nhóm, quy trình này nhanh chóng trở thành một công việc lặp lại
và dễ sai.

Hướng dẫn này chỉ cách xuất những thành viên mà tài khoản của bạn nhìn thấy
trong các nhóm đã tham gia sang CSV, Excel hoặc JSON.

Minh bạch: Tôi xây dựng Zalo Data Exporter. Nếu bạn đăng ký hoặc chạy
Actor qua liên kết trong bài, tôi có thể nhận doanh thu từ Apify mà bạn không
phải trả thêm.

“Quét thành viên nhóm Zalo” ở đây có nghĩa gì?

Đây không phải là công cụ tìm số điện thoại công khai hoặc xâm nhập nhóm ẩn.
Actor kết nối tài khoản Zalo của chính bạn bằng QR tạm thời và đọc dữ liệu hiển
thị cho tài khoản đó.

Kết quả được tách thành ba loại:

Dataset view	Dữ liệu chính
Groups	ID nhóm, tên nhóm, số thành viên hiển thị
Group members	ID nhóm, ID người dùng, tên hiển thị, khóa bản ghi
Contacts and profiles	Tên Zalo, avatar và mối quan hệ khi Zalo hiển thị

Tách view như vậy giúp bạn tải đúng bảng thay vì nhận một file JSON lộn xộn.

Quy trình từng bước

Bước 1: Chọn Group roster

Mở Zalo Data Exporter trên Apify
và giữ preset 👥 Group roster.

Không cần nhập cookie, token Zalo, IMEI, proxy hoặc mật khẩu phiên. Form chỉ hỏi
kết quả và giới hạn bạn muốn.

Bước 2: Giữ giới hạn lần đầu nhỏ

Khởi đầu với:

{
  "exportMode": "groupRoster",
  "accountAlias": "main",
  "maxGroups": 1,
  "maxMembersPerGroup": 100
}

Một nhóm và 100 thành viên đủ để kiểm tra toàn bộ workflow. Sau khi Dataset
đúng, tăng riêng giới hạn bạn cần.

Bước 3: Quét QR ngay khi run bắt đầu

Ở lần chạy đầu tiên:

Bấm Start.
Mở tab Output.
Bấm ① First run: scan this Zalo QR.
Quét và phê duyệt trong ứng dụng Zalo.
Giữ run mở cho đến khi Dataset xuất hiện.

QR có thời hạn ngắn. Nếu bạn nhận QR_EXPIRED, chạy lại và quét mã mới ngay.

Bước 4: Kiểm tra ba view

Mở Groups trước để chắc chắn bạn đã lấy đúng nhóm. Sau đó mở Group
members để xem danh sách. Cuối cùng, kiểm tra Contacts and profiles nếu
bạn cần thêm trường hồ sơ mà Zalo hiển thị.

Bước 5: Tải Excel, CSV hoặc JSON

Excel/CSV: phù hợp cho lọc, loại trùng, đối chiếu và nhập CRM;
JSON: phù hợp cho code, API hoặc kho dữ liệu;
Dataset API: phù hợp cho workflow định kỳ.

Dùng Python cho lần chạy sau

Sau khi đã kết nối QR một lần trong Console, bạn có thể tái sử dụng phiên đăng
nhập đã mã hóa:

import os
from apify_client import ApifyClient

client = ApifyClient(os.environ["APIFY_API_TOKEN"])
run = client.actor("kazkn/zalo-member-profile-exporter").call(run_input={
    "exportMode": "groupRoster",
    "accountAlias": "main",
    "maxGroups": 1,
    "maxMembersPerGroup": 100,
})

rows = client.dataset(run["defaultDatasetId"]).list_items().items
members = [row for row in rows if row.get("recordType") == "groupMember"]
print(f"{len(members)} visible members exported")

Mỗi tài khoản Zalo khác nên dùng một accountAlias khác. Không chia sẻ
APIFY_API_TOKEN và không dán token vào chatbot.

Làm sạch dữ liệu trước khi đưa vào CRM

Một danh sách thành viên không tự động trở thành lead list. Trước khi nhập CRM:

giữ recordKey hoặc cặp groupId + userId làm khóa ổn định;
giữ tên nhóm để biết nguồn của mỗi dòng;
không suy đoán số điện thoại khi trường đó không hiển thị;
loại trùng theo mục tiêu của bạn: một người có thể thuộc nhiều nhóm;
áp dụng thời hạn lưu trữ phù hợp với workflow của bạn.

Những giới hạn cần biết

Actor không đọc nhóm chưa tham gia, thành viên bị ẩn, tin nhắn đã xóa hoặc cơ
sở dữ liệu số điện thoại. Zalo có thể yêu cầu xác minh lại, giới hạn truy cập
hoặc thay đổi dữ liệu trả về. Vì vậy, hãy bắt đầu bằng một tài khoản không quan
trọng và phạm vi nhỏ.

FAQ

Có thể xuất toàn bộ thành viên của mọi nhóm Zalo không?

Không nên hiểu như vậy. Actor chỉ xuất thành viên hiển thị trong những nhóm mà
tài khoản đã kết nối có thể truy cập, trong giới hạn của run.

Có thể chọn một nhóm cụ thể không?

Có. Bạn có thể nhập ID của nhóm đã tham gia trong trường nâng cao. Cách đơn
giản nhất là chạy một lần nhỏ, lấy ID từ view Groups, rồi dùng ID đó ở run
tiếp theo.

Có cần cài phần mềm trên máy không?

Không. Actor chạy trên Apify. Bạn chỉ cần trình duyệt để cấu hình và điện thoại
để phê duyệt QR lần kết nối đầu tiên.

Chạy thử với một nhóm

Video ở đầu bài cho thấy toàn bộ quy trình từ QR đến Excel. Hãy lặp lại đúng
workflow đó với một nhóm và tối đa 100 thành viên trước khi mở rộng.

👉 Xuất thành viên nhóm Zalo ra Excel hoặc CSV

Liên kết Apify trong bài hỗ trợ nhà phát triển của Actor. Dữ liệu trả về phụ
thuộc vào quyền hiển thị của tài khoản đã kết nối.

Sao lưu tin nhắn Zalo ra CSV, Excel và JSON: hướng dẫn từng bước

KazKN — Sun, 09 Aug 2026 01:18:57 +0000

Bạn có thể sao lưu Zalo để đổi điện thoại. Nhưng khi cần tìm một câu trong hàng
nghìn tin nhắn, lọc theo ngày trong Excel hoặc đưa lịch sử chat vào một script,
bản sao lưu trong ứng dụng không phải là định dạng bạn cần.

Vấn đề thật sự là: làm sao xuất phần lịch sử Zalo mà tài khoản của bạn nhìn
thấy thành dữ liệu có cấu trúc?

Trong hướng dẫn này, tôi sẽ chỉ cách tạo một bản xuất giới hạn, đọc được trong
CSV, Excel hoặc JSON — đồng thời giải thích rõ những gì công cụ không thể lấy.

Minh bạch: Tôi là nhà phát triển của Zalo Data Exporter. Nếu bạn đăng ký
hoặc chạy Actor qua liên kết trong bài, tôi có thể nhận doanh thu từ Apify mà
bạn không phải trả thêm.

Sao lưu Zalo và xuất dữ liệu không giống nhau

Mục tiêu	Sao lưu trong Zalo	Xuất dữ liệu có cấu trúc
Khôi phục khi đổi điện thoại	Phù hợp	Không phải mục tiêu chính
Mở trong Excel	Hạn chế	Có
Lọc theo ngày, người gửi, cuộc trò chuyện	Hạn chế	Có
Dùng trong Python, BI hoặc kho dữ liệu	Không	Có, qua JSON/API
Khôi phục tin nhắn đã xóa	Không	Không
Đọc dữ liệu tài khoản không nhìn thấy	Không	Không

Nếu mục tiêu chỉ là đổi máy, hãy dùng tính năng sao lưu chính thức. Nếu mục tiêu
là phân tích hoặc lưu trữ bên ngoài Zalo, bạn cần một Dataset.

Một bản xuất chat hữu ích cần có gì?

Không nên gom mọi thứ vào một cột văn bản. Một Dataset tốt tách ít nhất hai loại
bản ghi:

conversation: ID, tiêu đề, loại cuộc trò chuyện, trạng thái đầy đủ và lý do dừng;
message: ID, cuộc trò chuyện, người gửi, chiều gửi/nhận, thời gian, nội dung và metadata tệp đính kèm nếu bạn bật tùy chọn đó.

Nhờ vậy, bạn có thể lọc tin nhắn theo ngày, tìm từ khóa trên nhiều cuộc trò
chuyện, đếm tin nhắn theo người gửi hoặc nhập JSON vào một pipeline.

Cách xuất lịch sử chat Zalo trên Apify

1. Mở Actor và chọn đúng preset

Mở Zalo Data Exporter,
sau đó chọn 💬 Conversation backup.

Preset này chỉ yêu cầu những giới hạn người dùng hiểu được: số cuộc trò chuyện,
số tin nhắn mỗi cuộc trò chuyện, mốc ngày, nội dung tin nhắn và metadata tệp.

2. Bắt đầu nhỏ

Lần đầu, dùng khoảng:

{
  "exportMode": "conversationBackup",
  "maxConversations": 3,
  "maxMessagesPerConversation": 200,
  "includeMessageText": true,
  "includeAttachmentMetadata": true
}

Ba cuộc trò chuyện và 200 tin nhắn mỗi cuộc giúp bạn kiểm tra đúng tài khoản,
đúng định dạng và đúng chi phí trước khi tăng giới hạn.

3. Quét mã QR tạm thời

Ở lần kết nối đầu tiên, bấm Start, mở Output → ① First run: scan this
Zalo QR, rồi quét bằng ứng dụng Zalo. QR chỉ tồn tại trong khoảng thời gian
ngắn. Nếu hết hạn, chạy lại để nhận mã mới.

Sau khi xác thực thành công, các lần chạy sau có thể dùng lại phiên đăng nhập đã
được mã hóa cho cùng accountAlias.

4. Đọc trạng thái trước khi tải file

Một run thành công không có nghĩa là toàn bộ lịch sử Zalo đã được đọc. Mỗi dòng
conversation cho biết điều gì đã dừng quá trình:

COMPLETE_TO_ZALO_WEB_START: Zalo Web đã trả về điểm bắt đầu thực tế;
PARTIAL_LIMIT: đã chạm mốc ngày hoặc giới hạn tin nhắn của bạn;
PARTIAL_ZALO_BOUNDARY: Zalo hoặc giới hạn an toàn đã dừng trước;
FAILED: cuộc trò chuyện đó không trả về kết quả an toàn.

Đây là phần quan trọng nhất nếu bạn muốn một bản lưu trữ đáng tin: đọc trạng
thái đầy đủ, không chỉ đếm số dòng.

5. Tải đúng Dataset view

Chọn Conversations để kiểm tra phạm vi và trạng thái.
Chọn Messages để tải nội dung tin nhắn.
Tải CSV/Excel để lọc trong bảng tính.
Tải JSON hoặc dùng Dataset API cho tự động hóa.

Gọi Actor bằng Python

Sau lần quét QR đầu tiên trong Console, bạn có thể chạy lại bằng API:

import os
from apify_client import ApifyClient

client = ApifyClient(os.environ["APIFY_API_TOKEN"])
run = client.actor("kazkn/zalo-member-profile-exporter").call(run_input={
    "exportMode": "conversationBackup",
    "accountAlias": "main",
    "maxConversations": 3,
    "maxMessagesPerConversation": 200,
})

items = client.dataset(run["defaultDatasetId"]).list_items().items
messages = [row for row in items if row.get("recordType") == "message"]
print(f"{len(messages)} messages exported")

Đừng đặt token trực tiếp trong code. Dùng biến môi trường
APIFY_API_TOKEN.

Những gì bản xuất không làm

Actor chỉ đọc dữ liệu hiển thị cho tài khoản đã kết nối. Nó không:

khôi phục tin nhắn đã xóa;
đọc nhóm mà tài khoản chưa tham gia;
lấy dữ liệu ẩn hoặc kho chỉ tồn tại trên thiết bị di động;
gửi tin nhắn hoặc thay đổi thành viên;
đảm bảo Zalo Web trả về toàn bộ lịch sử của mọi tài khoản.

FAQ

Có thể xuất tin nhắn Zalo ra Excel không?

Có. Chọn Conversation backup, chạy với giới hạn nhỏ, mở view Messages và
tải CSV hoặc Excel.

Có cần quét QR mỗi lần không?

Không nhất thiết. Lần đầu cần QR tạm thời; lần sau Actor có thể dùng lại phiên
đăng nhập đã mã hóa. Nếu phiên hết hạn hoặc bị Zalo thu hồi, bạn phải làm mới.

Có thể lấy tin nhắn đã xóa không?

Không. Công cụ chỉ xuất dữ liệu Zalo Web trả về cho tài khoản đang kết nối.

Bắt đầu với một bản xuất nhỏ

Đừng chạy toàn bộ tài khoản ngay. Bắt đầu với 3 cuộc trò chuyện, kiểm tra trạng
thái và định dạng, rồi mới tăng giới hạn phù hợp với nhu cầu.

👉 Chạy Zalo Conversation Backup trên Apify

Liên kết Apify trong bài hỗ trợ nhà phát triển của Actor. Kết quả phụ thuộc vào
dữ liệu mà tài khoản của bạn có thể nhìn thấy và giới hạn bạn chọn.

I Built an Apify Actor to Compare Luxury Handbag Resale Prices Across 4 Marketplaces

KazKN — Sun, 21 Jun 2026 01:01:25 +0000

I built an Apify Actor that compares public resale listings for Hermes Birkin, Hermes Kelly, and Chanel Classic Flap bags across four marketplaces:

Vestiaire Collective
Rebag
Fashionphile
1stDibs

Actor:

https://apify.com/kazkn/hermes-birkin-kelly-arbitrage

Short demo:

https://youtube.com/shorts/h0JEDFitqao?feature=share

The goal is not to build an auto-buy bot.

The goal is to turn messy marketplace pages into a dataset that can be reviewed before any human decision.

The Problem

Luxury resale comparison is messy because public listings are inconsistent.

One marketplace exposes condition clearly. Another hides useful data inside the detail page. One title includes hardware. Another only says "leather". One listing is priced low because condition is weaker. Another is priced high because the seller is testing the market.

Manual spreadsheet comparison breaks quickly.

The Actor turns that into a repeatable workflow:

Collect public listings.
Normalize listing fields.
Group comparable bags.
Calculate gross spread.
Estimate net ROI after cost assumptions.
Output review candidates and warnings.

Input Design

The input is designed for non-technical users first.

Main sections:

Scan scope
Strict target
Scan limits
Deal thresholds
Cost assumptions
Platform fee assumptions
Output and proxy settings

Users can run a broad scan:

{
  "platforms": ["vestiaire", "rebag", "fashionphile", "1stdibs"],
  "models": ["birkin", "kelly", "classic_flap"],
  "targetingMode": "broad_scan",
  "maxListingsPerMarketplace": 60,
  "maxPagesPerMarketplace": 1
}

Or they can run a strict watchlist:

{
  "targetingMode": "strict_target",
  "targetModel": "birkin",
  "targetSize": "30",
  "targetColor": "black",
  "targetMaterial": "togo",
  "targetHardware": "gold",
  "minimumCondition": "very_good"
}

The watchlist matters because many users already know the exact bag they want. They do not need every listing. They need to know whether a narrow target appears across platforms.

Normalization

The Actor normalizes fields like:

brand
model
size
colorBucket
materialBucket
hardwareBucket
conditionBucket
price
currency
platform
listingUrl

The hard part is not scraping the title.

The hard part is turning different marketplace language into comparable buckets without pretending incomplete data is perfect.

That is why the output includes warnings. A relaxed match is useful, but it is not the same as a strict match.

Spread And ROI

There are two gates.

Gross spread:

grossSpreadPercent = (referenceSellPrice - buyCandidatePrice) / buyCandidatePrice

Estimated net ROI:

estimatedNetRoiPercent = estimatedNetProfit / landedBuyPrice

The landed buy price can include:

shipping or insurance estimate
authentication or repair buffer
FX and tax buffer

The sell-side value deducts platform fee assumptions.

This is intentionally conservative. A listing can have a large headline spread and still become unattractive once costs are added.

Output Records

The dataset includes different record types:

normalized_listing
spread_candidate
watchlist_candidate
arbitrage_opportunity
unmatched_listing
platform_error
run_summary

I keep these separate because a scraper should not overstate confidence.

For example:

A spread_candidate means "review this".
An arbitrage_opportunity means stricter filters passed.
A platform_error means a marketplace failed and should not be silently ignored.
A run_summary helps you understand coverage, failures, and counts.

Why Apify

Apify is useful here because the workflow benefits from:

scheduled runs
proxy support
structured input schema
dataset output
API access
monetization support
readable actor logs

This kind of workflow is not a one-off script. Users want to run it daily, change scan scope, export results, and plug the dataset into another process.

Limitations

This Actor does not:

authenticate bags
guarantee resale profit
scrape private sales
provide investment advice
prove sold prices
bypass marketplace rules

It compares public active listings and makes the review process cleaner.

That boundary is important.

What I Would Improve Next

Useful next steps:

deeper detail page enrichment
better sold-comps integration where legally available
more marketplace-specific fee models
alerting for saved watchlists
CSV templates for reseller workflows
historical price tracking per model/size/material group

Try It

Actor:

https://apify.com/kazkn/hermes-birkin-kelly-arbitrage

Short demo:

https://youtube.com/shorts/h0JEDFitqao?feature=share

If you build Apify Actors, the main takeaway is not the luxury niche. The reusable pattern is:

public marketplace data -> normalized records -> comparable groups -> warnings -> review queue.

I Built the Wrong Scraper First. The Data Looked Clean and Was Still Useless.

KazKN — Fri, 12 Jun 2026 01:27:35 +0000

I built the wrong scraper first.

It worked.

That was the problem.

The scraper extracted product titles, prices, URLs, images, and brands. The dataset was clean. The rows looked normal. Nothing crashed.

But the output was still not useful enough.

The mistake was simple: I treated a resale marketplace like a product catalog.

It is not.

A marketplace has state.

The clean dataset trap

This looked fine:

{
  "title": "Leather bag",
  "price": 1200,
  "brand": "Example",
  "url": "https://example.com/item/123"
}

But the real questions were missing:

Is it live or sold?
Did it disappear since the last run?
Which country was searched?
Where is the seller?
What condition is the item in?
Has the price changed?
Is this listing unusually similar to another listing?

None of those questions are visible in a basic product-card scrape.

What I changed

I stopped designing the output around the page.

I started designing it around decisions.

The row became more explicit:

{
  "recordType": "listing",
  "displayStatus": "Available",
  "isSold": false,
  "country": "FR",
  "sellerCountry": "IT",
  "condition": "Very good condition",
  "price": 1200,
  "priceHistory": [],
  "requiresManualReview": false
}

Less pretty.

Much more useful.

The lesson

Selectors are not the product.

The state model is the product.

If the scraper cannot preserve state, it will make the dataset feel more certain than it really is.

That is dangerous because clean JSON is easy to trust.

The checklist I use now

Before I trust a marketplace scraper, I check whether it handles:

live items;
sold items;
disappearing items;
seller country;
page country;
item condition;
price history;
duplicate or similar listings;
manual-review signals.

If it does not, I treat the dataset as a starting point, not a decision layer.

The uncomfortable part

The broken version was easier to explain.

"It scrapes product data" is simple.

"It models marketplace state" takes longer.

But the second one is the version I would actually use.

Have you ever shipped a scraper that was technically correct but operationally useless?

Your Scraper Returns 200 OK and Still Lies: 7 Marketplace Checks I Use

KazKN — Fri, 12 Jun 2026 01:25:30 +0000

The easiest scraper bug to miss is not a crash.

It is a clean result that is wrong.

The request returns 200 OK.

The selector works.

The dataset has rows.

The dashboard looks alive.

And still, the output can lie.

That happens often on marketplaces because a marketplace is not just a list of product cards. It is a changing state machine.

Here is the checklist I now use before trusting marketplace scraping data.

1. Separate live records from sold records

Active listings and sold listings answer different questions.

Active listings show supply.

Sold listings show demand.

If both go into one dataset without a clear recordType, later analysis gets unreliable.

{
  "recordType": "listing",
  "isSold": false
}

{
  "recordType": "sold_item",
  "isSold": true
}

2. Treat disappearance as an event

If a listing disappears, do not silently delete it from your mental model.

Emit a tracking record.

{
  "recordType": "tracking_event",
  "event": "previously_seen_listing_missing",
  "listingId": "123"
}

You may not know whether it sold, expired, or was removed.

But you do know something changed.

3. Store page country and seller country separately

This one sounds minor until it breaks your analysis.

country can mean the market page you searched.

sellerCountry can mean the seller location exposed by the listing.

Those are not the same thing.

{
  "country": "DE",
  "sellerCountry": "FR"
}

If you merge them, your cross-market analysis becomes noise.

4. Add precision filters after broad search

Marketplace search is optimized for discovery, not clean datasets.

A broad query often returns nearby products.

So I like a second layer:

{
  "searchTerms": ["classic flap"],
  "requiredKeywords": ["classic", "flap"]
}

This does not make search perfect.

It makes the dataset easier to inspect.

5. Make condition a first-class field

Price without condition is incomplete.

For resale marketplaces, condition changes the meaning of every price.

{
  "price": 1000,
  "condition": "Very good condition",
  "conditionSource": "marketplace"
}

If condition is hidden in a description string, you will forget to use it.

6. Track price history, not only price

One scrape tells you what existed.

Repeated scrapes tell you what changed.

{
  "priceHistory": [
    { "price": 1400, "observedAt": "2026-06-01T12:00:00.000Z" },
    { "price": 1200, "observedAt": "2026-06-08T12:00:00.000Z" }
  ]
}

For monitoring, the delta is usually more useful than the snapshot.

7. Use risk signals as review queues

Do not make accusations from scraper output.

If listings look suspiciously similar, surface them as review candidates.

{
  "recordType": "risk_signal",
  "signalType": "similar_listing_cluster",
  "confidence": "review_required"
}

That gives a human a useful queue without pretending the scraper has certainty.

The real test

I do not trust a marketplace scraper because it extracts rows.

I trust it when it preserves enough context to answer:

what exists now?
what sold?
what disappeared?
where was it found?
where is the seller?
did the price change?
what needs manual review?

That is the difference between scraping a page and modeling a marketplace.

What check would you add before trusting marketplace data in production?

AI Agents Make Scraping Look Easy. Marketplace State Is Where They Lie.

KazKN — Fri, 12 Jun 2026 01:25:28 +0000

AI agents make scraping look easy.

Give the agent a page.

Ask for JSON.

Get back a clean object.

{
  "title": "Leather bag",
  "price": 1200,
  "url": "https://example.com/item/123"
}

That feels useful.

It is often not enough.

The hard part of marketplace scraping is not always extracting the card.

The hard part is knowing whether the card still means what you think it means.

200 OK can still be wrong

A scraper can return a valid HTTP response, parse the page, extract the title and price, and still give you bad operational data.

The page did load.

The selector did work.

The JSON did validate.

But the marketplace state may be wrong.

Examples:

The item is visible in search but already sold.
The item disappeared, but you do not know whether it sold or was deleted.
The same listing appears across several market locales.
The seller country matters more than the page country.
The search term matches a nearby model, not the model you wanted.
The current price looks low, but the item condition explains why.
The product card hides details that only exist on the item page.

This is where AI extraction can create false confidence.

It makes the data look cleaner than the marketplace really is.

The mistake: treating marketplaces like catalogs

A catalog has products.

A marketplace has state.

For a catalog scrape, this might be enough:

{
  "title": "Product name",
  "price": 49,
  "availability": "In stock"
}

For a resale marketplace, I want a different shape:

{
  "recordType": "listing",
  "listingId": "123",
  "displayStatus": "Available",
  "isSold": false,
  "country": "FR",
  "sellerCountry": "IT",
  "condition": "Very good condition",
  "price": 1200,
  "priceHistory": [
    { "price": 1400, "observedAt": "2026-06-01T12:00:00.000Z" },
    { "price": 1200, "observedAt": "2026-06-08T12:00:00.000Z" }
  ],
  "requiresManualReview": false
}

That object is less pretty.

It is also more honest.

The seven checks I use now

Before trusting marketplace data, I want seven checks.

1. Live and sold records should not be mixed

Active listings tell you supply.

Sold listings tell you demand.

If both are pushed into the same flat dataset without a clear recordType, analysis becomes messy quickly.

2. Disappearance is a signal

If an item was present yesterday and missing today, the scraper should not silently forget it.

It should emit a tracking record.

Something changed.

That change may be more useful than another active listing.

3. Page country is not seller country

On international marketplaces, the locale you searched and the seller location are different concepts.

If you only store one country field, you will eventually confuse yourself.

I prefer:

{
  "country": "FR",
  "sellerCountry": "IT"
}

One tells me where I searched.

The other tells me where the seller appears to be.

4. Search terms need precision filters

Marketplace search is fuzzy.

That is useful for browsing.

It is dangerous for automation.

If the query is classic flap, I want the option to require those words in the result, not merely trust the search engine.

5. Condition changes the meaning of price

A low price without condition is not a deal.

It is just incomplete data.

I want condition and conditionSource visible in the output.

6. Price history matters more than current price

The current price is a snapshot.

The price movement is the signal.

If a scraper runs repeatedly, it should preserve enough state to answer:

did the price drop?
did it rise?
how long has it stayed at this level?
did it disappear after the drop?

7. Risk signals should be review queues, not accusations

If two listings look unusually similar, that is worth surfacing.

But a scraper should not declare fraud.

The safer output is:

{
  "recordType": "risk_signal",
  "signalType": "similar_listing_cluster",
  "confidence": "review_required"
}

That gives the human a queue.

It does not pretend the scraper knows more than it does.

Where AI helps

AI can still help a lot.

It can normalize messy titles.

It can classify categories.

It can summarize product descriptions.

It can help detect weird edge cases in extracted records.

But I do not want AI to hide uncertainty.

For marketplace scraping, the best output is not the cleanest JSON.

The best output is the JSON that preserves enough context to make a decision.

My rule now

If a scraper cannot explain state, I do not trust its clean output.

I want to know:

what exists now;
what disappeared;
what sold;
where it was found;
where the seller appears to be;
how the price changed;
what needs manual review.

Selectors are only the first layer.

The real product is the state model.

What is the most dangerous false-positive your scraper has returned?