4 endpoint trên service REST. Mỗi endpoint có khối test riêng, dùng Base URL / key ở khối Cấu hình test.

1.1 · Health check

Kiểm tra service REST còn sống. Không cần key — dùng cho monitor. Service stream có health riêng (GET /health trên base URL stream), trả thêm số subscriber đang kết nối.

Response 200

{ "ok": true }

Health của service stream:

{ "ok": true, "subscribers": 3 }

1.2 · Danh sách tin

Endpoint danh sách duy nhất, và nó trả lời cả hai câu hỏi: “kho có gì” (con trỏ chạy được hai chiều, lọc theo loại / mã sản phẩm / khoảng ngày) và “đang có tin gì mới” (mặc định mới nhất trước, nên gọi trần GET /v1/news chính là các bản ghi mới nhất — đúng thứ stream ở §2 đẩy tới bạn).

body là HTML (xem §3.1); như mọi danh sách, thân bài chỉ là bản xem trước ngắn (excerpt: true) — nguyên văn một bài lấy ở §1.3.

Query parameters

Tất cả đều tùy chọn và kết hợp được với nhau (điều kiện AND). Không truyền gì = 100 bản ghi mới nhất.

Ví dụ

# 20 tin mới nhất — cũng chính là cách poll
GET /v1/news?limit=20

# Poll vòng sau: chỉ những gì mới hơn con trỏ đã lưu
GET /v1/news?since_id=18342

# Bài viết về đồng hoặc quặng sắt trong tháng 9
GET /v1/news?products=CPE,FEF&from=2026-09-01&to=2026-09-30

# Tin thuộc nhóm Kim loại hoặc Năng lượng (gõ không dấu cũng được) — nhớ URL-encode
GET /v1/news?categories=kim%20loai,nang%20luong

# Lật tiếp về quá khứ: dùng next_before_id của trang trước
GET /v1/news?limit=20&before_id=18310

# Cũ nhất trước, nối tiếp từ con trỏ đã lưu
GET /v1/news?order=asc&since_id=18342

Response 200

{
  "items": [
    {
      "id": 18342,
      "title": "Đồng lên đỉnh ba tuần nhờ kỳ vọng nhu cầu Trung Quốc",
      "body": "<p>Giá đồng tăng lên mức cao nhất trong ba tuần khi thị trường kỳ vọng nhu cầu từ Trung Quốc phục hồi sau loạt biện pháp...</p>",
      "excerpt": true,
      "published_at": "2026-08-31T09:12:00+00:00",
      "fetched_at": "2026-08-31T09:20:14+00:00",
      "categories": ["Kim loại", "Kinh tế vĩ mô"],
      "country": "Trung Quốc",
      "products": ["CPE"],
      "content_kind": "article",
      "featured_image_url": "https://cdn.example.com/ai-news/18342.jpg",
      "metadata": {}
    }
  ],
  "next_since_id": 18342,
  "next_before_id": 18342,
  "count": 1
}

Field cấp ngoài

1.3 · Chi tiết một bản ghi

Một bản ghi theo id, thân bài nguyên văn. Đây là endpoint bạn gọi sau khi nhận một item từ danh sách hoặc stream — id ở đó chính là id ở đây.

Response là chính đối tượng Article ở cấp cao nhất (không bọc trong items), cùng bộ field như §3.

1.4 · Danh mục sản phẩm

Danh mục sản phẩm hàng hóa phía sau trường products của Article. Mã ở đây chính là mã bạn nhận trong products và là mã dùng cho tham số lọc products của §1.2 — dùng endpoint này để đổi mã thành tên hiển thị (CPE → Đồng) hoặc dựng bộ lọc.

Không có tham số. Trả toàn bộ danh mục trong một response, không phân trang.

Response 200

{
  "items": [
    { "code": "AHD", "name": "Nhôm LME", "productGroup": "Kim loại", "exchanger": "LME" },
    { "code": "ALI", "name": "Nhôm COMEX", "productGroup": "Kim loại", "exchanger": "COMEX" }
  ],
  "count": 50,
  "synced_at": "2026-10-20T03:00:12+00:00"
}

Danh mục được hệ thống tự cập nhật mỗi ngày một lần; dữ liệu giá/ký quỹ của nguồn không nằm trong response này. Không cần gọi thường xuyên — cache phía bạn khoảng một ngày là đủ.

Một service riêng, base URL riêng. Kết nối bằng Server-Sent Events.

Xác thực

Cả hai nhận key theo thứ tự: Authorization: Bearer <key> → X-API-Key → ?key= trên query string. Key phải có scope articles (xem §9).

2.1 · Server-Sent Events

Khung sự kiện trên dây

data: {"event":"translated","id":18343,"title":"Tồn kho dầu thô Mỹ giảm 2,1 triệu thùng","content_kind":"article","fetched_at":"2026-08-31T14:02:09+00:00","metadata":{}, … }

: keepalive

Ví dụ — JavaScript

const base = 'https://ai-news-socket.sfi.com.vn';
const seen = new Set();                      // at-least-once → tự khử trùng lặp

const es = new EventSource(`${base}/stream/news?key=${KEY}`);

// Frame không có dòng `event:`, nên onmessage nhận mọi tin.
es.onmessage = (e) => {
  const item = JSON.parse(e.data);
  if (seen.has(item.id)) return;
  seen.add(item.id);

  if (item.excerpt) {
    // cần nguyên văn thì gọi REST bằng chính id này
  }
  render(item);
};

es.onerror = () => { /* EventSource tự reconnect — nhưng KHÔNG bù phần đã lỡ */ };

Ví dụ — curl

curl -N -H "Authorization: Bearer <key>" \
  "https://ai-news-socket.sfi.com.vn/stream/news"

const ws = new WebSocket(`wss://…/ws/news?key=${KEY}`);

ws.onmessage = (e) => {
  const m = JSON.parse(e.data);
  if (m.event === 'ping') return;           // keepalive
  if (seen.has(m.id)) return;               // khử trùng lặp
  seen.add(m.id);
  render(m);
};

ws.onclose = (e) => {
  if (e.code === 4401) return;              // key sai — reconnect vô nghĩa
  setTimeout(connect, backoff());           // 1013 và mọi trường hợp khác
};

Một cấu trúc dùng chung cho tất cả các endpoint và cả stream. Khác biệt giữa các nơi được ghi rõ ở cột cuối.

* body không bao giờ null, nhưng có thể bị cắt — “không null” và “đầy đủ” là hai chuyện khác nhau, hãy đọc excerpt.

3.1 · body — đặc tả HTML và cách render

body là một đoạn HTML, không phải Markdown và không phải văn bản thuần. Chèn thẳng vào trang của bạn là xong — không cần thư viện Markdown, và không phải lo hai bên render ra hai kết quả khác nhau.

Những thẻ có thể xuất hiện

Không có <script>, <style>, <iframe>, thuộc tính on*, hay style= nội tuyến — xem ghi chú an toàn bên dưới.

Ví dụ

"body": "<h2>Đồng lên đỉnh ba tuần</h2>\n<p>Giá <strong>đồng</strong> tăng lên mức cao nhất trong ba tuần…</p>\n<ul>\n<li>Tồn kho giảm</li>\n</ul>"

Một bản xem trước (excerpt: true) luôn là đúng một đoạn văn:

"body": "<p>Giá đồng tăng lên mức cao nhất trong ba tuần khi thị trường kỳ vọng nhu cầu từ Trung Quốc phục hồi sau loạt biện pháp...</p>",
"excerpt": true

Đoạn xem trước cố tình không giữ tiêu đề mục, danh sách hay ảnh của bài: cắt HTML theo số từ sẽ để lại thẻ hở, và một đoạn nhử tin thì không cần tới bố cục của bài mà nó nhử.

3.2 · metadata — dữ liệu của nguồn, không phải của chúng tôi

Mọi field khác trong payload là do hệ thống này tạo ra (title, body, categories, fetched_at) hoặc là một giá trị đơn lẻ lấy nguyên từ nguồn (published_at). metadata là ngoại lệ duy nhất: đó là dữ liệu có cấu trúc do chính nguồn tin đính kèm cho item, được trả về đúng như nguồn gửi.

Nó không có schema, và đây là chủ ý chứ không phải thiếu sót. Mỗi nguồn đính kèm một thứ khác nhau, nên chuẩn hóa lại thành một hình dạng chung thì hoặc phải bỏ mất dữ liệu bạn có thể cần, hoặc phải bịa ra một cấu trúc mà không nguồn nào thực sự dùng. Quy tắc khi đọc:

• Mọi key đều là tùy chọn. Key chỉ xuất hiện khi item thực sự có nó — không có nghĩa là null, mà là không có key.
• Phần lớn bản ghi trả về {}. Đa số nguồn không đính kèm gì cả. Đừng coi {} là lỗi hay là "chưa xử lý xong".
• Đừng rẽ nhánh logic theo việc object có rỗng hay không, và đừng coi bất kỳ key nào là điều kiện để hiển thị tin. Tin vẫn đầy đủ khi metadata rỗng.
• Key mới có thể xuất hiện bất cứ lúc nào mà không đổi phiên bản, vì chỉ cần nguồn gửi thêm một field là nó có ở đây.

Hiện chưa có key nào được cam kết. Nếu một nguồn đính kèm dữ liệu, bạn sẽ thấy nó ở đây nguyên dạng — hãy đọc theo kiểu “có thì dùng, không có thì bỏ qua”.

Mục này giải thích phần dễ gây khó chịu nhất: vì sao thân bài bị cắt, và xử lý thế nào cho đúng.

Vì sao cắt

Danh sách sinh ra để báo “có tin này, đây là id” càng rẻ càng tốt. Nếu đẩy nguyên thân bài tới mọi subscriber ở mọi sự kiện thì stream sẽ nặng hơn hàng trăm lần so với thứ nó được thiết kế để chở, và một trang 100 bản ghi cũng nặng tương tự so với việc nó chỉ cần trả lời “có gì”. Trong khi đó phần lớn consumer chỉ hiển thị tiêu đề trong danh sách rồi mới tải nội dung khi người dùng bấm vào.

// Cách xử lý đúng, phía consumer
if (item.excerpt) {
    const full = await fetch(`${REST}/v1/news/${item.id}`, { headers });
    item.body = (await full.json()).body;
}

Không có page, không có offset, không có total. Phân trang bằng con trỏ id, chạy được cả hai chiều, và mỗi response trả sẵn con trỏ cho cả hai: next_since_id (bản ghi mới nhất trang này) và next_before_id (cũ nhất).

Đọc bù về phía trước — since_id

Câu hỏi “có gì mới hơn thứ tôi đã xử lý”. Đây cũng là cách lấp khoảng trống sau khi stream đứt.

let cursor = 0;
for (;;) {
  const r = await get(`/v1/news?since_id=${cursor}&order=asc&limit=100`);
  if (r.count === 0) break;          // hết dữ liệu
  for (const item of r.items) handle(item);
  cursor = r.next_since_id;          // luôn tiến, không bao giờ lùi
  if (r.count < 100) break;          // trang cuối
}

Lật về quá khứ — before_id

Câu hỏi “cho tôi xem tiếp phía dưới”. Dùng với /v1/news (mặc định đã giảm dần) — đây là kiểu cuộn vô hạn của một trang tin.

let before = 0;                      // 0 = bắt đầu từ mới nhất
for (;;) {
  const r = await get(`/v1/news?before_id=${before}&limit=20`);
  if (r.count === 0) break;
  for (const item of r.items) render(item);
  before = r.next_before_id;         // luôn lùi dần về quá khứ
  if (r.count < 20) break;           // đã tới bản ghi cũ nhất
}

Lọc

Bộ lọc chỉ có trên /v1/news — stream không lọc được gì. Các bộ lọc kết hợp với nhau bằng AND. Đặc tả đầy đủ ở §1.2. Những điểm dễ nhầm:

• products=CPE,FEF là OR — bài nhắc tới bất kỳ mã nào trong danh sách, không phải bài nhắc tới tất cả.
• categories=kim loai,nang luong cũng là OR, không phân biệt hoa thường và dấu tiếng Việt, nhưng phải khớp trọn tên nhóm — không có tìm theo một phần chữ.
• from/to tính trên fetched_at (thời điểm hệ thống thu thập), không phải published_at — xem ghi chú ở §1.2. Dạng ngày thì to bao trọn ngày đó.
• Bộ lọc không đổi ý nghĩa con trỏ: count < limit vẫn là dấu hiệu hết dữ liệu, nhưng là hết dữ liệu khớp bộ lọc, không phải hết toàn bộ kho.

1. Nạp lần đầu — phân trang /v1/news?order=asc&since_id=0&limit=100 cho tới khi count < limit. Lưu id lớn nhất làm con trỏ. (Chỉ cần một quãng gần đây thì thêm from= thay vì kéo lại từ đầu.)
2. Chạy thường xuyên — mở stream (SSE). Stream không nhận con trỏ: nó chở tin phát sinh kể từ lúc kết nối. Cập nhật con trỏ của bạn sau mỗi item đã xử lý xong, không phải lúc vừa nhận.
3. Với item excerpt: true — nếu bạn cần nguyên văn ngay, gọi /v1/news/{id}. Nếu chỉ hiển thị danh sách, cứ để preview và chỉ tải chi tiết khi người dùng bấm vào.
4. Khi mất kết nối — reconnect có backoff, rồi lấp khoảng trống bằng REST: /v1/news?order=asc&since_id=<con trỏ − 50> cho tới khi bắt kịp. Trừ 50 là để bù phần id cấp hơi lệch thứ tự; phần trùng thì khử theo id. Bước này bắt buộc — stream không tự phát bù.
5. Trang duyệt / trang tìm kiếm phía bạn — dùng /v1/news với before_id để cuộn, kèm products, categories, from/to theo bộ lọc người dùng chọn. Đừng tự tải hết về rồi lọc ở client: bộ lọc chạy ở database rẻ hơn nhiều lần.
6. Lưu nội dung phía bạn. API là nguồn cấp, không phải kho lưu trữ: dữ liệu cũ sẽ bị dọn, và một item hôm nay lấy được thì ngày mai chưa chắc còn.

• Key được cấp theo scope. Scope articles mở GET /v1/news, GET /v1/news/{id} và stream. Thiếu scope thì trả 401 kèm tên scope endpoint đó cần.
• Hệ thống chỉ lưu hash SHA-256 của key, nên bản rõ chỉ hiện đúng một lần lúc tạo. Mất thì phải cấp key mới, không khôi phục được.
• Ưu tiên header Authorization: Bearer hoặc X-API-Key. REST không nhận key qua query string — đúng để nó không rơi vào access log. Stream có nhận ?key=, nhưng chỉ vì trình duyệt không đặt được header trên SSE.
• Đừng nhúng key vào frontend công khai. Trang này nhận key chỉ để test thủ công và lưu trong localStorage của chính trình duyệt bạn. Ứng dụng thật nên gọi qua backend của mình.
• CORS mở cho mọi origin trên /v1/* và trên stream. Điều đó không nới lỏng bảo mật: mọi request vẫn phải có key hợp lệ, và một key thì gọi bằng curl cũng được.
• Chỉ đọc. Không có endpoint ghi, không có endpoint xóa. Không thao tác nào từ phía bạn thay đổi được dữ liệu.
• Hai service tách rời. REST và stream chạy độc lập — một cái chết không kéo cái kia theo, và hàng nghìn kết nối stream cũng không làm chậm REST. Health check riêng cho từng cái.

Áp dụng cho /api/news (cả ba cách) và /api/reports (chỉ cách 1.1).

1.1 · Lấy tin mới (cũ trước — mặc định)

Truyền since là id của bản ghi cuối cùng đã lấy, hệ thống trả về những bản ghi mới hơn.

# Lần đầu
GET /api/news?since=0           -> { "items": [...], "next_since": 1483 }

# Lần tiếp (chưa có tin mới)
GET /api/news?since=1483        -> { "items": [], "next_since": 1483 }

# Lần tiếp (có tin mới)
GET /api/news?since=1483        -> { "items": [...], "next_since": 1490 }

Lưu next_since lại, truyền vào lần gọi sau. Không bao giờ trả trùng, không bao giờ bỏ sót. Khi không có dữ liệu mới, items rỗng và next_since giữ nguyên — phản hồi rất nhẹ.

1.2 · Cuộn về tin cũ (mới trước) v1.4

Dùng cho màn danh sách cuộn vô hạn: lần đầu lấy tin mới nhất, cuộn xuống thì lấy tiếp tin cũ hơn. Chỉ áp dụng cho /api/news.

# Lần đầu
GET /api/news?order=desc&limit=20
  -> { "items": [745, 744, …, 726], "next_before": 726, "has_more": true }

# Cuộn tiếp
GET /api/news?order=desc&limit=20&before=726
  -> { "items": [725, …, 706], "next_before": 706, … }

Dừng khi has_more là false.

1.3 · Quy tắc con trỏ khi có bộ lọc v1.4

• Luôn truyền lại nguyên next_since / next_before mà server trả về. Không tự tính từ id lớn nhất / nhỏ nhất trong items. Khi lọc, server có thể duyệt qua nhiều tin không khớp; con trỏ trả về đã tính cả các tin đó nên lần gọi sau không duyệt lại, không bỏ sót.
• count < limit không có nghĩa là hết dữ liệu khi có bộ lọc. Dấu hiệu hết dữ liệu là has_more: false.
• Mỗi lượt gọi có bộ lọc duyệt tối đa 20.000 tin. Nếu chưa đủ limit tin khớp, phản hồi trả số tin đã tìm được kèm has_more: true — gọi tiếp bằng con trỏ để lấy phần còn lại.

2.1 · Tham số

Các bộ lọc kết hợp với nhau theo AND. Không truyền tham số mới = kết quả như các bản trước.

Ví dụ

# Tin mới như cũ (gọi 5 giây/lần)
GET /api/news?since=1483

# 20 tin đồng mới nhất
GET /api/news?products=CPE&order=desc&limit=20

# Tin cà phê (Arabica hoặc Robusta) trong tháng 10
GET /api/news?products=KCE,LRC&from=2026-10-01&to=2026-10-31&order=desc

# Tin nhóm Kim loại hoặc Năng lượng, gõ không dấu
GET /api/news?categories=kim%20loai,nang%20luong&order=desc&limit=20

# Gọi định kỳ lấy tin mới chỉ của nhóm Nông sản
GET /api/news?categories=nong%20san&since=1483

2.2 · Phản hồi

{
  "items": [
    {
      "id": 1483,
      "posted_at": "2026-10-13T16:31:48+07:00",
      "source": "mkt",
      "category": "Nông sản",
      "level": "",
      "important": false,
      "speaker": "",
      "title": "Argentina bỏ thuế xuất khẩu ngũ cốc",
      "body": "Mức thuế đậu tương về 0% cho tới ngày 31/10.",
      "text_vi": "【Argentina bỏ thuế xuất khẩu ngũ cốc】Mức thuế đậu tương về 0% cho tới 31/10.",
      "text_en": "Argentina suspends export taxes on soybeans and corn until 31/10.",
      "tags": [
        { "symbol": "ZS", "name_vi": "Đậu tương", "kind": "hang_hoa",
          "impact": "bearish", "impact_vi": "Tiêu cực" },
        { "symbol": "ZC", "name_vi": "Ngô", "kind": "hang_hoa",
          "impact": "bearish", "impact_vi": "Tiêu cực" }
      ],
      "msg_id": 1800,
      "products": ["ZSE", "ZCE"],
      "categories": ["Nông sản"]
    }
  ],
  "count": 1,
  "next_since": 1483,
  "next_before": 1483,
  "has_more": false
}

Trường cấp ngoài

Giải thích các trường của tin

2.3 · Mức độ quan trọng (level)

Thứ tự mức độ: red > warn > yellow > rỗng.

2.4 · Thẻ tác động (tags)

Mỗi tin có thể kèm một hoặc nhiều thẻ, cho biết tin đó liên quan tới mã hàng hóa, chỉ số, tiền tệ nào và hướng tác động tới giá. Thẻ do MKTNews gắn tự động tại nguồn; hệ thống chỉ bổ sung tên tiếng Việt và phân nhóm để tiện hiển thị.

Nhãn hiển thị của hướng tác động

Nhãn tiếng Việt do API sinh ra, không phải do ứng dụng tự dịch. Nếu bên nghiệp vụ muốn đổi cách gọi, bên vận hành sửa trên máy chủ và ứng dụng tự đổi theo — không cần phát hành bản mới. Vì vậy đề nghị hiển thị trực tiếp giá trị impact_vi, không hard-code bảng dịch trong ứng dụng.

2.5 · Tin gộp và tin nối thêm

Trên Telegram, bot có hai cách đưa nhiều ý vào cùng một tin nhắn. API ghi cả hai, mỗi trường hợp theo một cách:

Hệ quả cho ứng dụng:

• msg_id không duy nhất: nhiều dòng có thể cùng msg_id. Không dùng msg_id làm khoá chính. Khoá chính là id.
• Muốn hiển thị giống Telegram (gom theo tin nhắn) thì nhóm các dòng cùng msg_id, sắp theo id tăng dần. Muốn hiển thị dạng dòng tin thì dùng từng dòng như bình thường.
• msg_id có thể null (hiếm).

2.6 · Mã sản phẩm (products) và nhóm (categories) v1.4

Hai trường này giúp tab Tin nóng lọc giống các tab AI News Feed. Cả hai do API tính khi trả dữ liệu, nên tin cũ cũng có.

products — mã sản phẩm SFI

Hệ thống đọc nội dung tin (bản gốc tiếng Anh) và thẻ MKTNews để gắn mã. Chỉ gắn mã chính của mỗi mặt hàng — không gắn các bản mini/micro/nano hay mã LME trùng tên (vd tin đồng chỉ gắn CPE, không gắn MQC, MHG, CAD…). Một tin có thể có nhiều mã.

Quy tắc khi tin nói chung chung (không ghi rõ loại)

categories — nhóm theo bộ AI News Feed

Giá trị: Nông sản · Nguyên liệu công nghiệp · Kim loại · Năng lượng · Kinh tế vĩ mô · Khác.

2.7 · Ghi chú về bộ lọc v1.4

• Bộ lọc chạy trên máy chủ. Đề nghị không tải hết tin về rồi lọc ở ứng dụng.
• products=CPE,ZCE là OR (tin nhắc đồng hoặc ngô). products + categories là AND.
• from / to theo giờ Việt Nam (khác AI News Feed của tab Tin thường, tính theo UTC), so trên posted_at.
• Có thể dùng since (gọi định kỳ lấy tin mới) cùng bộ lọc: ?products=KCE,LRC&since=<next_since>.

3.1 · Tham số và phản hồi

{
  "items": [
    {
      "id": 1,
      "posted_at": "2026-10-02T18:07:24+07:00",
      "report": "cot",
      "report_name": "COT – Quỹ đầu cơ (CFTC)",
      "period": "2026-09-22",
      "caption": "",
      "images": [
        "cot_2026-09-22_1.png",
        "cot_2026-09-22_2.png"
      ]
    }
  ],
  "count": 1,
  "next_since": 1
}

caption rỗng ở các báo cáo lịch sử. Báo cáo chỉ có con trỏ since / next_since (cách ở §1.1), không có order, before hay bộ lọc.

3.2 · Danh sách mã báo cáo

Kỳ đầu tiên của 4 báo cáo mới xuất hiện trong API khi nguồn công bố kỳ tiếp theo (dự kiến từ 21/10/2026).

3.3 · Định dạng period

Định dạng không thống nhất giữa các báo cáo. Hãy coi period là chuỗi: chỉ dùng để hiển thị và so sánh bằng, không chuyển sang kiểu ngày tháng.

Với unica_sugar, period là ngày chốt số của UNICA (vd 2026-08-01 = số liệu luỹ kế tới 01/08). Các báo cáo mới khác: coi period là chuỗi như trên.

Truyền tên file lấy từ mảng images ở §3.1. Trả về file PNG, kiểu image/png.

GET /api/reports/image/cot_2026-09-22_1.png
X-API-Key: <khoá>

Ảnh là biểu bảng số liệu đã dựng sẵn theo mẫu của công ty, khoảng 2100 × 1000 điểm ảnh, dung lượng 100–300 KB mỗi ảnh. Kích thước ảnh khác nhau giữa các báo cáo — ứng dụng nên co ảnh theo khung, không cố định kích thước.

Test — GET /api/reports/image/{tên_file}

tên file

Gửi request

chưa gọi

Không cần khoá. Dùng cho hệ thống giám sát.

{
  "ok": true,
  "news":    { "total": 737, "last_id": 737 },
  "reports": { "total": 18,  "last_id": 18 }
}

Khi hệ thống gặp sự cố, phản hồi trả về ok: false kèm mã HTTP 500; khối news hoặc reports khi đó chứa trường error mô tả nguyên nhân. Đây là dấu hiệu để hệ thống giám sát báo động.

Python — gọi định kỳ lấy tin mới

import time, requests
BASE = "http://42.96.44.143:8080"
KEY  = "..."
since = 0
while True:
    r = requests.get(f"{BASE}/api/news",
                     params={"since": since, "limit": 100},
                     headers={"X-API-Key": KEY}, timeout=10)
    if r.status_code == 429:
        time.sleep(1); continue
    r.raise_for_status()
    d = r.json()
    for it in d["items"]:
        print(it["posted_at"], it["categories"], it["products"], it["text_vi"])
    since = d["next_since"]
    time.sleep(5)

Python — danh sách tin đồng, cuộn về tin cũ v1.4

before = 0
while True:
    r = requests.get(f"{BASE}/api/news",
                     params={"products": "CPE", "order": "desc",
                             "limit": 20, "before": before},
                     headers={"X-API-Key": KEY}, timeout=10)
    d = r.json()
    for it in d["items"]:
        print(it["id"], it["text_vi"])
    if not d["has_more"]:
        break
    before = d["next_before"]     # luôn lấy con trỏ server trả về

C#

var http = new HttpClient();
http.DefaultRequestHeaders.Add("X-API-Key", KEY);
int since = 0;
while (true) {
    var res = await http.GetFromJsonAsync<NewsResponse>(
        $"{BASE}/api/news?since={since}&limit=100");
    foreach (var it in res.items)
        Console.WriteLine($"{it.posted_at} {string.Join(",", it.products)} {it.text_vi}");
    since = res.next_since;
    await Task.Delay(5000);
}

Thử nhanh bằng curl

curl -H "X-API-Key: <khoá>" \
     "http://42.96.44.143:8080/api/news?products=CPE,ZCE&order=desc&limit=5"

curl -H "X-API-Key: <khoá>" \
     "http://42.96.44.143:8080/api/reports?since=0&limit=2"

curl -H "X-API-Key: <khoá>" -o thu.png \
     "http://42.96.44.143:8080/api/reports/image/cot_2026-09-22_1.png"