SEC EDGAR API bằng Python: CIK, accession và hồ sơ công bố
SEC EDGAR API bằng Python là cách đọc danh mục hồ sơ công bố của một công ty niêm yết tại Mỹ qua kênh chính thức data.sec.gov. Kết quả là bảng hồ sơ có mã CIK, số accession, loại form, ngày nộp và đường dẫn gốc. Bài chỉ bàn metadata hồ sơ, không phân tích báo cáo tài chính và không đưa khuyến nghị đầu tư nào. ProxyVN chạy thử ngày 29/10/2026 với Apple Inc.: 1.002 hồ sơ gần nhất cộng 1.268 hồ sơ cũ, và một request thiếu khai báo User-Agent bị SEC trả 403 ngay lập tức.
SEC EDGAR API bằng Python: mục tiêu dữ liệu, quyền và phạm vi truy cập
Phần đầu chốt mình lấy gì từ EDGAR, chính sách truy cập của SEC và những việc bài cố ý không làm.
EDGAR là gì
EDGAR là hệ thống nộp và công bố hồ sơ điện tử của Ủy ban Chứng khoán và Giao dịch Mỹ. Công ty niêm yết, quỹ, cổ đông lớn và người nội bộ nộp các loại form như 10-K báo cáo năm, 10-Q báo cáo quý, 8-K sự kiện bất thường, Form 4 giao dịch của người nội bộ.
Toàn bộ hồ sơ là thông tin công khai. SEC cung cấp API JSON tại data.sec.gov để máy đọc được danh mục hồ sơ và dữ liệu XBRL mà không phải parse trang HTML. Danh sách endpoint và khuôn dữ liệu nằm ở trang EDGAR Application Programming Interfaces của SEC.
Đầu ra mà bài này hướng tới
Đầu ra là tệp CSV, mỗi dòng là một hồ sơ. Cột gồm CIK, accession, form, filingDate, reportDate, acceptanceDateTime, tên tài liệu chính và URL trang chỉ mục của hồ sơ trên sec.gov.
Bảng này trả lời câu hỏi công ty đã nộp những gì, khi nào, và tài liệu gốc nằm ở đâu. Nó là điểm bắt đầu cho người cần đọc hồ sơ gốc, không phải bảng số liệu tài chính.
Không phải khuyến nghị đầu tư
Bài dùng Apple làm công ty mẫu vì hồ sơ nhiều và đa dạng. Việc chọn công ty không mang ý nghĩa đánh giá nào. Bài không bàn giá cổ phiếu, không bình luận kết quả kinh doanh và không gợi ý mua bán.
Nếu anh em dùng dữ liệu EDGAR cho quyết định tài chính, hãy đọc hồ sơ gốc và hỏi người có chuyên môn. Bảng metadata chỉ cho biết hồ sơ tồn tại, không cho biết nên làm gì với nó.
Chính sách truy cập của SEC
SEC công bố chính sách truy cập công bằng cho EDGAR. Theo trang Accessing EDGAR Data, mỗi người dùng giới hạn tối đa 10 request mỗi giây, và request phải khai User-Agent có tên ứng dụng hoặc tổ chức kèm email liên hệ.
Request vượt nhịp hoặc không khai báo có thể bị chặn tạm thời. Chính sách này áp cho cả sec.gov lẫn data.sec.gov.
Không cần khóa API
data.sec.gov không có khóa API, không đăng ký, không token. Định danh duy nhất là chuỗi User-Agent. Vì vậy chuỗi này đóng vai trò quan trọng hơn nhiều so với các API khác.
Đừng đặt User-Agent giả như một trình duyệt. SEC muốn biết ai đang gọi để liên hệ khi có vấn đề, không phải để phân biệt người với máy.
Những gì bài không làm
Bài không tải toàn văn mọi hồ sơ, không tải các bản dump hằng đêm, không parse nội dung 10-K. Bài không hướng dẫn chia request qua nhiều IP để vượt 10 request mỗi giây, vì đó là lẩn tránh chính sách công khai của SEC.
Loại form nào cần cho việc gì
Mỗi loại form phục vụ một mục đích. 10-K là báo cáo năm đầy đủ, có phần mô tả hoạt động, rủi ro và báo cáo tài chính đã kiểm toán. 10-Q là báo cáo quý, ngắn hơn và chưa kiểm toán. 8-K báo sự kiện như thay đổi lãnh đạo hay thương vụ lớn.
Form 3, 4 và 5 là khai báo sở hữu của người nội bộ. Form 144 là thông báo ý định bán chứng khoán bị hạn chế. 424B2 và FWP liên quan tới phát hành chứng khoán nợ. Biết nghĩa của form giúp anh em lọc đúng ngay từ đầu, thay vì tải cả nghìn hồ sơ không cần.
Danh sách form và ý nghĩa nằm trên trang của SEC. Bảng của bài giữ nguyên mã form như SEC ghi, không tự đặt nhãn tiếng Việt, để tránh dịch sai khi đối chiếu.
Ai cần bảng hồ sơ này
Nhà nghiên cứu cần danh sách 10-K của một công ty qua nhiều năm để đọc lại phần rủi ro. Nhóm tuân thủ cần theo dõi Form 4 của người nội bộ ở công ty đối tác. Nhà báo cần biết công ty vừa nộp 8-K gì trong tuần.
Cả ba đều bắt đầu bằng bảng metadata. Từ bảng, họ mở đúng hồ sơ gốc cần đọc, thay vì lục tìm trên trang web.
Lấy metadata hồ sơ công bố qua kênh SEC chính thức bằng SEC EDGAR API bằng Python, chuẩn hóa CIK/accession và tuân thủ chính sách truy cập
Phần này đi qua ba bước: từ ticker ra CIK, từ CIK ra danh mục hồ sơ, và từ accession ra đường dẫn gốc.
Từ ticker ra CIK
CIK là mã định danh trung tâm của SEC cho mỗi đơn vị nộp hồ sơ. Ticker có thể đổi, CIK thì không. SEC công bố tệp company_tickers.json ánh xạ ticker sang CIK.
Lab tải tệp này: 200 trong 0,94 giây, 798.077 byte, 10.430 mục. Dòng của AAPL là cik_str 320193, title Apple Inc. Tệp có Last-Modified là 26/10/2026 và Cache-Control max-age 49 giây.
CIK mười chữ số

CIK mười chữ số
Endpoint submissions đòi CIK đủ mười chữ số, đệm số không ở đầu. 320193 thành 0000320193. Lab gọi thử bản không đệm và nhận 404.
Trong code, giữ CIK dạng số nguyên làm khóa, và tạo chuỗi mười chữ số bằng f-string với định dạng 010d khi ghép URL. Đừng lưu chuỗi đệm làm khóa, vì so sánh chuỗi với số dễ sai.
Endpoint submissions
import requests, time
H = {"User-Agent": "ProxyVN-lab lab@example.com"}
tk = requests.get("https://www.sec.gov/files/company_tickers.json",
headers=H, timeout=30).json()
row = next(v for v in tk.values() if v["ticker"] == "AAPL")
cik = int(row["cik_str"])
time.sleep(0.2)
s = requests.get(f"https://data.sec.gov/submissions/CIK{cik:010d}.json",
headers=H, timeout=30).json()
rec = s["filings"]["recent"]
print(s["name"], len(rec["accessionNumber"]))
Lab nhận 200 trong 0,60 giây, 163.917 byte nén gzip. name là Apple Inc., sic 3571, fiscalYearEnd 0926. Khối filings.recent có 1.002 hồ sơ.
Khuôn dữ liệu dạng cột
filings.recent không phải danh sách hồ sơ mà là một từ điển các mảng song song. accessionNumber là một mảng, form là một mảng, filingDate là một mảng, cùng độ dài. Hồ sơ thứ i là phần tử thứ i của mọi mảng.
Lab đếm 16 mảng, gồm acceptanceDateTime, act, fileNumber, filingDate, filmNumber, form, isXBRL, isInlineXBRL, items, primaryDocument, primaryDocDescription, reportDate, size và vài trường khác. Chuyển sang dạng dòng bằng cách đi theo chỉ số.
Accession là khóa của hồ sơ
Số accession dạng 0000320193-25-000079 gồm ba phần: mã của bên nộp, hai chữ số năm, số thứ tự trong năm. Phần đầu là CIK của bên nộp, không nhất thiết là công ty được báo cáo.
Lab thấy nhiều hồ sơ Form 4 của Apple có accession bắt đầu bằng 0001140361, là mã của đại lý nộp hồ sơ. Đây là lý do không được tách CIK công ty từ accession. Luôn lấy CIK từ ngữ cảnh truy vấn.
Dựng đường dẫn gốc
Trang chỉ mục của hồ sơ nằm ở sec.gov/Archives/edgar/data/ cộng CIK không đệm, cộng accession bỏ gạch ngang, cộng accession có gạch ngang và đuôi -index.htm. Tài liệu chính nằm trong cùng thư mục với tên primaryDocument.
Ví dụ 10-K năm 2025 của Apple: accession 0000320193-25-000079, nộp 31/10/2025, kỳ báo cáo 27/09/2025, tài liệu chính aapl-20250927.htm. Bảng giữ URL trang chỉ mục để người đọc mở thẳng.
Ranh giới với dữ liệu XBRL
data.sec.gov còn có companyconcept và companyfacts, trả số liệu XBRL đã gắn thẻ. Lab gọi thử: companyconcept Revenues của Apple trả 200 với đơn vị USD, companyfacts trả 3,79 MB với hai bộ phân loại dei và us-gaap.
Bài chỉ ghi nhận các endpoint này tồn tại và hoạt động. Phân tích số liệu tài chính nằm ngoài phạm vi bài, và dễ bị hiểu thành nhận định đầu tư.
Chuẩn bị truy vấn, ID, token và phiên bản API khi dùng SEC EDGAR API bằng Python
Phần này gom các quyết định trước khi chạy thật: User-Agent, nhịp request, nén và cache.
User-Agent theo đúng mẫu SEC
SEC hướng dẫn mẫu User-Agent gồm tên tổ chức hoặc ứng dụng và email liên hệ, ví dụ Sample Company Name [email protected]. Lab dùng ProxyVN-lab [email protected]. Khi chạy thật, thay bằng tên và email thật của nhóm.
Email phải là địa chỉ có người đọc. SEC có thể gửi thư khi request của anh em gây vấn đề. Dùng email giả trong sản phẩm thật là tự cắt đường liên lạc đó.
User-Agent mặc định bị chặn
Lab gọi submissions của Apple mà không đặt header, requests tự gửi python-requests/2.34.2. SEC trả 403 trong 0,39 giây, trang HTML có tiêu đề nói request đến từ công cụ không khai báo.
Đây là lỗi phổ biến nhất khi mới dùng EDGAR. Code chạy được trên trình duyệt nhưng bị chặn trong Python. Sửa bằng cách đặt header User-Agent đúng mẫu cho mọi request, kể cả request tới www.sec.gov.
Không có token, không có phiên bản trên URL
data.sec.gov không có tham số phiên bản. Khuôn JSON có thể thay đổi khi SEC bổ sung trường. Code nên đọc trường theo tên và chịu được trường mới, không giả định số mảng cố định.
Lab ghi danh sách khóa của filings.recent vào tệp kết quả. Khi lần chạy sau thấy khóa mới hay mất khóa cũ, đó là tín hiệu cần xem lại code.
Nhịp request
Giới hạn 10 request mỗi giây là trần, không phải mục tiêu. Lab nghỉ một giây giữa các request, tức khoảng một phần mười trần. Với vài chục công ty, nhịp này chạy xong trong vài phút.
Khi cần nhiều nghìn công ty, SEC cung cấp bản nén submissions.zip và companyfacts.zip cập nhật hằng đêm. Tải một tệp nén lớn nhẹ cho SEC hơn nhiều so với hàng nghìn request riêng lẻ.
Nén gzip
Response của data.sec.gov có Content-Encoding gzip, và requests tự giải nén. Con số 163.917 byte mà lab ghi là độ dài nội dung sau giải nén. Lưu lượng thật trên dây nhỏ hơn nhiều.
Bài gzip và brotli khi web scraping giải thích vì sao nên giữ Accept-Encoding mặc định thay vì tắt nén.
Cache theo Last-Modified
company_tickers.json có Last-Modified và Cache-Control. Lần chạy sau gửi If-Modified-Since, nếu nhận 304 thì dùng bản cũ. Tệp này đổi theo ngày, không cần tải lại mỗi lần chạy script.
Submissions của một công ty đổi khi công ty nộp hồ sơ mới. Lưu kết quả với thời điểm tải, chỉ làm mới khi cần.
Môi trường lab
Python 3.12.10, requests 2.34.2, csv và json của thư viện chuẩn. Không dùng thư viện bọc riêng, để thấy rõ từng request và header. Ghi phiên bản vào requirements.txt.
Thu dữ liệu có phân trang hoặc trạng thái job theo đúng nguồn với SEC EDGAR API bằng Python
EDGAR không phân trang theo tham số. Hồ sơ cũ nằm ở tệp phụ. Phần này ghi kết quả chạy thật và cách ghép.
Kết quả gọi thật ngày 29/10/2026
Request |
Mã |
Giây |
Kết quả |
|---|---|---|---|
company_tickers.json |
200 |
0,94 |
10.430 mục |
submissions CIK0000320193 |
200 |
0,60 |
1.002 hồ sơ gần nhất |
tệp phụ submissions-001 |
200 |
0,79 |
1.268 hồ sơ cũ |
companyconcept Revenues |
200 |
0,61 |
Đơn vị USD |
companyfacts |
200 |
0,66 |
3,79 MB, dei và us-gaap |
submissions CIK không đệm |
404 |
không ghi |
Không tìm thấy |
submissions CIK9999999999 |
404 |
không ghi |
NoSuchKey dạng XML |
submissions, User-Agent mặc định |
403 |
0,39 |
Công cụ không khai báo |
Mọi request có User-Agent đúng mẫu đều nhanh, dưới một giây. Request thiếu khai báo bị chặn còn nhanh hơn.
Tệp phụ thay cho phân trang
Khối filings.recent chứa tối đa khoảng một nghìn hồ sơ gần nhất, hoặc một năm, tùy cái nào nhiều hơn. Hồ sơ cũ hơn nằm trong danh sách filings.files, mỗi mục có name, filingCount, filingFrom và filingTo.
Với Apple, có một tệp phụ CIK0000320193-submissions-001.json với 1.268 hồ sơ từ 26/01/1994 tới 01/10/2015. Khối recent bắt đầu từ 02/10/2015. Hai phần nối liền nhau theo ngày.
Ghép recent với tệp phụ

recent + tệp phụ
def to_rows(cik, block):
out = []
for i, acc in enumerate(block["accessionNumber"]):
out.append({"cik": cik, "accession": acc, "form": block["form"][i],
"filingDate": block["filingDate"][i],
"reportDate": block["reportDate"][i],
"primaryDocument": block["primaryDocument"][i]})
return out
rows = to_rows(cik, rec)
for f in s["filings"].get("files", []):
time.sleep(1)
j = requests.get(f"https://data.sec.gov/submissions/{f['name']}",
headers=H, timeout=30).json()
rows += to_rows(cik, j)
Tệp phụ có khuôn giống hệt khối recent, các mảng song song ở cấp ngoài cùng. Cùng một hàm chuyển đổi dùng được cho cả hai.
Đối chiếu filingCount
Mỗi mục trong filings.files có filingCount. Lab so số hồ sơ đọc được từ tệp phụ với filingCount: 1.268 bằng 1.268. Phép so này bắt được trường hợp tệp phụ bị cắt hoặc tải hỏng.
filingTo của tệp phụ ghi 01/10/2015, nhưng hồ sơ cuối cùng trong tệp có ngày 18/09/2015. Không có hồ sơ nào trong khoảng giữa, nên filingTo là ranh giới khoảng chứ không phải ngày của hồ sơ cuối.
Phân bố form trong 1.002 hồ sơ gần nhất
Form |
Số hồ sơ |
|---|---|
4 |
601 |
8-K |
101 |
144 |
50 |
424B2 |
42 |
10-Q |
33 |
PX14A6G |
27 |
SC 13G/A |
22 |
FWP |
21 |
3 |
12 |
DEFA14A |
12 |
Form 4 chiếm hơn một nửa. Ai chỉ cần 10-K và 10-Q sẽ phải lọc lại. Khối recent không có tham số lọc theo form trên server, việc lọc làm trong Python.
Lọc theo form trong Python
Sau khi có bảng dòng, lọc bằng một tập form cần lấy. Ví dụ tập gồm 10-K, 10-Q và 8-K. Với Apple, lọc trên khối recent cho 145 hồ sơ thuộc ba loại này, cộng 2 bản sửa có hậu tố /A, phần còn lại chủ yếu là Form 4.
Chú ý các biến thể có hậu tố /A, như 10-K/A, là bản sửa của hồ sơ gốc. Nếu chỉ lọc đúng chuỗi 10-K, bản sửa sẽ bị bỏ sót. Quyết định giữ hay bỏ bản sửa tùy mục đích, nhưng hãy quyết định có chủ ý.
Trường items của 8-K
Với hồ sơ 8-K, trường items liệt kê mã mục được báo cáo, ví dụ 2.02 cho kết quả hoạt động hay 5.02 cho thay đổi nhân sự cấp cao. Trường này là chuỗi, nhiều mục cách nhau bằng dấu phẩy.
Tách items thành danh sách khi cần lọc theo loại sự kiện. Với form khác 8-K, items thường rỗng. Bảng của bài giữ items dạng chuỗi gốc để không mất thông tin.
Không có job bất đồng bộ
Mọi endpoint của data.sec.gov là tệp JSON tĩnh được dựng sẵn và phục vụ qua CDN. Không có job, không có trạng thái chờ. Thông báo lỗi 404 dạng XML NoSuchKey cho thấy tệp nằm trên kho lưu trữ đối tượng phía sau.
Điều này giải thích vì sao mọi request đều nhanh. Nhưng nó cũng có nghĩa dữ liệu có độ trễ so với lúc hồ sơ được chấp nhận. SEC ghi submissions cập nhật gần thời gian thực, lab không đo độ trễ này.
Đối soát ID, kiểu dữ liệu, giá trị thiếu và xuất xứ trong SEC EDGAR API bằng Python
Có bảng rồi, việc tiếp theo là kiểm khóa, kiểu ngày và các ô trống.
Accession là duy nhất
Lab đếm 1.002 accession khác nhau trong 1.002 hồ sơ recent. Sau khi ghép tệp phụ, kiểm lại toàn bộ 2.270 accession cũng phải khác nhau. Trùng là dấu hiệu ghép một tệp hai lần.
Khóa chính của bảng là accession. CIK là khóa ngoại tới bảng công ty. Một hồ sơ có thể liên quan nhiều CIK, ví dụ Form 4 liên quan cả công ty và người nội bộ, nhưng bảng của bài chỉ nhìn từ phía công ty.
reportDate trống
221 trong 1.002 hồ sơ có reportDate là chuỗi rỗng. Phần lớn là các form không gắn với một kỳ báo cáo, như 424B2 hay FWP. Ô trống ở đây là đúng nghĩa, không phải dữ liệu lỗi.
Khi phân tích theo kỳ, chỉ dùng hồ sơ có reportDate. Khi phân tích theo thời gian nộp, dùng filingDate, trường này luôn có.
Ba mốc thời gian khác nhau

Ba mốc thời gian
filingDate là ngày nộp. reportDate là ngày kết thúc kỳ báo cáo. acceptanceDateTime là thời điểm hệ thống chấp nhận hồ sơ, có giờ và hậu tố Z cho UTC. Ba trường mang ba ý nghĩa.
10-K năm 2025 của Apple có reportDate 27/09/2025, filingDate 31/10/2025 và acceptanceDateTime 31/10/2025 lúc 10:01:26 UTC. Kỳ kết thúc tháng 9, hồ sơ nộp cuối tháng 10.
Kiểu dữ liệu
CIK trong company_tickers là số nguyên, trong submissions là chuỗi mười chữ số. size là số nguyên byte. isXBRL và isInlineXBRL là số 0 hoặc 1, không phải boolean. Ngày là chuỗi ISO.
Chuẩn hóa ngay khi ghi bảng: CIK về số nguyên, ngày về kiểu date, cờ về boolean. Giữ bản JSON thô để tra lại khi cần.
Giữ xuất xứ cho từng dòng
Mỗi dòng có URL trang chỉ mục trên sec.gov. Người đọc mở ra là thấy danh sách tệp của hồ sơ, đúng như SEC công bố. Ghi thêm thời điểm tải và URL endpoint đã dùng vào tệp nhật ký.
Bài JSON và CSV khi crawl dữ liệu bàn khi nào nên giữ thêm JSON thô. Với EDGAR, JSON thô của submissions chỉ vài trăm KB mỗi công ty, giữ lại rất rẻ.
Tên công ty đổi theo thời gian
Trường formerNames trong submissions liệt kê các tên cũ cùng khoảng thời gian dùng. Lab đọc được ba tên cũ của Apple: APPLE COMPUTER INC từ 1994 tới đầu 2007, APPLE COMPUTER INC/ FA trong một ngày năm 1997, và APPLE INC từ 2007 tới 2019 trước khi đổi cách viết hiện tại. Khi đối chiếu hồ sơ cũ với nguồn khác, tìm theo CIK thay vì theo tên.
Bảng kết quả của bài ghi tên hiện tại ở phần đầu tệp. Nếu cần tên tại thời điểm nộp, tra formerNames theo filingDate.
Lưu kết quả, giới hạn request và khi nào SEC EDGAR API bằng Python cần proxy
Phần cuối bàn chuyện lưu trữ, nhịp gọi và vị trí đúng của proxy với một nguồn có chính sách truy cập rõ ràng.
Lưu bảng hồ sơ
Tệp 289_filings.csv của lab có 1.002 dòng và tám cột cho khối recent. Mỗi lần chạy ghi tệp mới có ngày trong tên. So hai tệp liền nhau để thấy hồ sơ mới theo accession.
Giữ dưới 10 request mỗi giây
Đặt bộ giới hạn nhịp trong code thay vì tin vào time.sleep rải rác. Khi chạy nhiều luồng, bộ giới hạn phải dùng chung giữa các luồng. Mười luồng mỗi luồng một request mỗi giây đã chạm trần.
Bài rate limit API khi dùng proxy có mẫu bộ đếm theo cửa sổ thời gian. Áp vào EDGAR với trần thấp hơn 10 để còn dư cho các script khác của cùng tổ chức.
Khi bị chặn
Khi nhận 403 có User-Agent đúng mẫu, thường là do vượt nhịp. SEC mô tả việc chặn là tạm thời. Dừng job, giảm nhịp, chờ rồi chạy lại. Ghi nội dung trang lỗi vào nhật ký.
Không đổi User-Agent, không đổi IP để tiếp tục. Chính sách SEC tính theo người dùng, đổi đường đi để vượt là lẩn tránh chính sách công khai.
Ghi nhật ký mỗi lần chạy
Nhật ký nên có thời điểm chạy, User-Agent đã dùng, danh sách CIK, số request, mã trạng thái từng request, số hồ sơ mỗi công ty và số tệp phụ đã ghép. Khi số hồ sơ giảm so với lần trước, đó là dấu hiệu lỗi tải hoặc tệp phụ bị bỏ sót, vì hồ sơ EDGAR không bị xóa.
Đừng ghi email thật vào nhật ký công khai. Nếu nhật ký được chia sẻ, che phần email trong chuỗi User-Agent.
Proxy trong lab kiểm ở đâu
Lab chạy proxy HTTP có xác thực và proxy SOCKS5 cục bộ, rồi gọi submissions của Apple qua từng loại với User-Agent đúng mẫu.
Cách gọi |
Kết quả |
Proxy thấy gì |
|---|---|---|
Proxy HTTP có xác thực |
200 sau 0,82 giây |
CONNECT data.sec.gov:443 |
Proxy SOCKS5h |
200 sau 0,52 giây |
Tên miền data.sec.gov, cổng 443 |
Proxy HTTP sai mật khẩu |
ProxyError |
Request dừng ở proxy |
Với HTTPS, proxy không thấy User-Agent hay đường dẫn, chỉ thấy tên máy và cổng. SEC vẫn nhận đúng User-Agent mà script gửi. Proxy không thay thế khai báo định danh.
User-Agent vẫn bắt buộc khi đi qua proxy
Một số người nghĩ đi qua proxy thì không cần khai báo vì IP đã khác. Sai. SEC chặn theo cả User-Agent lẫn hành vi. Request không khai báo đi qua proxy vẫn nhận 403, chỉ là từ IP khác.
Bài User-Agent là gì giải thích chuỗi này được máy chủ dùng thế nào.
Khi nào cần proxy thật
Proxy cần khi máy chạy pipeline nằm trong mạng nội bộ chỉ được ra Internet qua proxy. Trường hợp thứ hai là tổ chức yêu cầu lưu lượng ra ngoài đi qua một IP cố định để giám sát. Cấu hình và mã hóa mật khẩu có ký tự đặc biệt có trong bài định dạng proxy.
Bài Web Scraping proxy là gì phân biệt các vai trò của proxy. Với EDGAR, vai trò hợp lý là đường đi mạng, không phải tăng hạn mức.
Khi máy chủ của nhóm đặt tại Việt Nam và cần một IP thoát ổn định để quản trị mạng cho phép đi ra ngoài, proxy tĩnh dễ quản lý hơn proxy xoay. ProxyVN có proxy dân cư tĩnh, datacenter, 4G và proxy xoay qua HTTP hoặc SOCKS5. Anh em có thể mua proxy Việt Nam tại trang chủ ProxyVN rồi khai báo vào requests theo tham số proxies.
Giới hạn suy luận của bài
Số liệu đến từ một lần chạy ngày 29/10/2026 với một công ty là Apple Inc. Công ty khác có thể không có tệp phụ, hoặc có nhiều tệp phụ. Lab không đo độ trễ giữa lúc hồ sơ được chấp nhận và lúc xuất hiện trên data.sec.gov.
Lab không chạm trần 10 request mỗi giây, không thử bản nén hằng đêm, không parse nội dung hồ sơ và không thử proxy thương mại. Bài không đưa ra bất kỳ nhận định nào về Apple hay cổ phiếu của công ty.
Checklist SEC EDGAR API bằng Python

Checklist SEC EDGAR API
- Đặt User-Agent có tên và email thật cho mọi request.
- Tra CIK từ company_tickers.json, giữ CIK dạng số nguyên.
- Đệm CIK đủ mười chữ số khi ghép URL submissions.
- Đổi khuôn mảng song song sang dạng dòng theo chỉ số.
- Ghép tệp phụ trong filings.files, so với filingCount.
- Khóa chính là accession, không tách CIK từ accession.
- Phân biệt filingDate, reportDate và acceptanceDateTime.
- Giữ dưới 10 request mỗi giây, bị chặn thì dừng.
Câu hỏi thường gặp về SEC EDGAR API bằng Python
SEC EDGAR có cần khóa API không?
Không. Chỉ cần User-Agent có tên và email liên hệ. Thiếu khai báo sẽ bị 403.
Vì sao gọi submissions bị 404?
Thường do CIK chưa đệm đủ mười chữ số. 320193 phải viết thành 0000320193.
Làm sao lấy hồ sơ cũ hơn một nghìn hồ sơ gần nhất?
Đọc danh sách filings.files trong submissions, tải từng tệp phụ và ghép theo cùng khuôn.
Accession có chứa CIK của công ty không?
Phần đầu accession là mã của bên nộp, có thể là đại lý. Lấy CIK từ ngữ cảnh truy vấn, không tách từ accession.
Đi qua proxy có cần khai User-Agent không?
Có. Proxy không thay thế định danh, SEC vẫn đọc User-Agent trong request.
Bài này có phân tích báo cáo tài chính không?
Không. Bài chỉ dựng bảng metadata hồ sơ và không đưa khuyến nghị đầu tư.
SEC EDGAR API bằng Python và những điều cần nhớ
SEC EDGAR API bằng Python cho anh em bảng hồ sơ công bố có CIK, accession, form, ngày nộp và đường dẫn gốc, chỉ với một User-Agent khai báo đúng. Lab ngày 29/10/2026 lấy 1.002 hồ sơ gần nhất và 1.268 hồ sơ cũ của Apple, còn request thiếu khai báo bị 403 ngay. Đệm CIK, ghép tệp phụ, giữ dưới 10 request mỗi giây. Cần IP thoát cố định cho pipeline chạy SEC EDGAR API bằng Python, liên hệ Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam.