Thanh toán và lỗi OpenAPI

Trang này áp dụng cho /api/v1/data/*, các API độc quyền của nền tảng Felo OpenAPI. Các cuộc gọi sử dụng số dư nền tảng, một số dư tín dụng dịch vụ tính bằng USD. Chúng không tiêu tốn tín dụng Felo Pro. Các Felo APIs cũ dưới /v2 sử dụng tín dụng Pro.

Đọc giá hiện tại

curl -sS https://openapi.felo.ai/api/v1/data/prices

Endpoint công khai này không cần khóa. Hãy khớp các mục của nó theo mã thao tác và đọc mức giá hiện tại cùng đơn vị tính phí; đừng giả định mọi thao tác đều có cùng chi phí hoặc cố định một mức giá từ ví dụ vào ứng dụng của bạn.

Một truy vấn trạng thái miễn phí không làm cho việc tạo hay xuất bên dưới trở thành miễn phí. Với X, phân trang và các bản ghi lồng nhau được trả về có thể làm tăng mức sử dụng tính phí.

Số dư và khoản giữ chỗ

Trước khi thực thi, dịch vụ có thể giữ chỗ đủ số dư cho thao tác. Công việc thành công sẽ được quyết toán trên khoản giữ chỗ đó; thất bại đã xác nhận sẽ giải phóng nó. Với tác vụ không đồng bộ, việc trả về một ID không có nghĩa là thanh toán đã hoàn tất.

Định giá trang PPT giữ chỗ mười trang khi tạo. Việc tạo thành công sẽ quyết toán đầu ra thực tế và giải phóng phần tiền chưa dùng. Tạo và xuất là các khoản phí riêng biệt. Xem quy trình PPT để biết hành vi xuất lại.

Nếu việc thực thi hoặc quyết toán không chắc chắn, một khoản giữ chỗ có thể vẫn đang chờ trong khi dịch vụ đối soát. Đừng coi mọi timeout hoặc 5xx là bằng chứng rằng không có việc gì xảy ra hoặc rằng một yêu cầu lặp lại là miễn phí.

Xem số dư khả dụng và mức sử dụng của bạn trong Console Billing. Để xem hướng dẫn nạp tiền ở cấp tài khoản, xem Thanh toán và Tín dụng.

Truy vấn mức sử dụng ví thông qua API

Chủ tài khoản có thể kiểm tra bản ghi cuộc gọi ví bằng Felo login token. Thông tin xác thực này khác với API Key dùng cho các cuộc gọi Data API; đừng thay thế bằng FELO_API_KEY.

curl -sS 'https://openapi.felo.ai/api/wallet/usage?call_type=data' \
  -H 'Authorization: Bearer YOUR_FELO_LOGIN_TOKEN'

Các bản ghi nằm trong data.items; call_type=data lọc các cuộc gọi khả năng. So sánh mức sử dụng với giá hiện tại của tài khoản. Đọc bản ghi không gửi thêm một tác vụ tạo nào nữa. Console Billing vẫn có sẵn để xem xét tài khoản và nạp tiền.

Đọc lỗi một cách phòng thủ

Kiểm tra trạng thái HTTP trước. Lỗi có thể dùng một trong hai dạng này; các giá trị bên dưới chỉ mang tính minh họa:

{"error":{"code":"invalid_parameter","message":"Check the request fields"},"request_id":"example-request-id"}

{"status":402,"code":"INSUFFICIENT_BALANCE","message":"Insufficient balance","request_id":"example-request-id"}

Đọc error.code / error.message khi có, nếu không thì code / message. Giữ lại request_id khi được trả về. Các phản hồi thành công thay đổi theo thao tác; đừng ép tất cả chúng vào cùng một lỗi hoặc khung data.

Quyết định bước tiếp theo

execution_unconfirmed (409) và billing_settlement_pending (503) cần đặc biệt cẩn trọng: đừng gửi lại ngay công việc có tính phí. Hãy truy vấn các tác vụ đã biết hoặc liên hệ hỗ trợ với request ID. Trạng thái HTTP thành công nhưng kết quả rỗng khác với phản hồi lỗi.

Thử lại mà không tạo công việc trùng lặp

• Với các truy vấn chỉ đọc trạng thái tác vụ và trạng thái xuất, hãy dùng backoff có giới hạn và tôn trọng Retry-After khi có.
• Với một yêu cầu tạo thất bại nhưng đã lưu task_id, hãy truy vấn tác vụ đó trước khi tạo một tác vụ khác.
• Nếu kết nối thất bại trước khi bạn nhận được ID, kết quả có thể không xác định. Đừng cho rằng gửi lại sẽ khử trùng lặp cho yêu cầu.
• Với 429, phân biệt giới hạn tốc độ ngắn hạn với cửa sổ hạn mức API key; thử lại lặp đi lặp lại không thể đặt lại hạn mức.
• Dừng thử lại sau một hạn chót đã cấu hình và hiển thị lỗi có thể hành động cho người gọi.

Khi cần hỗ trợ, hãy cung cấp endpoint, thời gian gần đúng, trạng thái HTTP và request ID. Đừng bao giờ bao gồm toàn bộ API key.