ວັນ 0
ພິສູດການເຂົ້າເຖິງ
ສ້າງ key, ດຳເນີນການຮ້ອງຂໍທີ່ຜ່ານການຢືນຢັນຕົວຕົນໜຶ່ງຄັ້ງ, ແລະ ບັນທຶກການຕອບສະໜອງຄັ້ງທຳອິດພ້ອມກັບ metadata ຂອງມັນ.
ເປີດຂັ້ນຕອນ →ຄູ່ມືຂັ້ນຕອນການເຮັດວຽກ API
ທ່ານຕ້ອງການສ້າງຫຍັງ?
ເລືອກຜົນລັດທີ່ໃກ້ຄຽງກັບວຽກຂອງທ່ານທີ່ສຸດ. ແຕ່ລະເສັ້ນທາງຈະໃຫ້ຄຳຮ້ອງຂໍທີ່ໃຊ້ງານໄດ້ໜຶ່ງລາຍການ, ສິ່ງທີ່ການຕອບສະໜອງຄວນມີ, ວິທີກວດສອບວ່າການເຮັດວຽກສຳເລັດ, ແລະ ຂັ້ນຕອນທີ່ມີປະໂຫຍດຕໍ່ໄປ.
ຫ້າເສັ້ນທາງທີ່ນຳໃຊ້ໄດ້ຈິງ
ເລີ່ມຕົ້ນດ້ວຍຜົນລັດ, ບໍ່ແມ່ນລາຍການ endpoint.
Selected: Troubleshoot a request
ເສັ້ນທາງ 1
ດຶງຂໍ້ມູນ macro
ດຶງຂໍ້ມູນອະນຸກົມເວລາທີ່ສະອາດ ແລະ ເກັບຮັກສາ metadata ຂອງແຫຼ່ງທີ່ມາ ແລະ ຄຸນນະພາບໄວ້ຄຽງຄູ່ກັນ.
ເສັ້ນທາງ 2
ວາງແຜນວຽກການເຜີຍແຜ່
ໃຊ້ປະຕິທິນການປ່ອຍຂໍ້ມູນເພື່ອລັນວຽກທີ່ກຳນົດເປົ້າໝາຍອ້ອມຮອບເວລາການເຜີຍແຜ່ທີ່ຮູ້ຈັກ.
ເສັ້ນທາງ 3
ວັດແທກສິ່ງທີ່ເກີດຂຶ້ນນອກເໜືອຈາກການຄາດການ
ລວມການພະຍາກອນກ່ອນການປ່ອຍຂໍ້ມູນເຂົ້າກັບຄ່າທີ່ຖືກເຜີຍແຜ່ ໂດຍບໍ່ເຮັດໃຫ້ເກີດ lookahead bias.
ເສັ້ນທາງ 4
ຮັບການອັບເດດສົດ
ໃຊ້ SSE ເປັນສັນຍານການຍົກເລີກ, ຈາກນັ້ນດຶງຂໍ້ມູນຄົບຖ້ວນຈາກ REST.
ເສັ້ນທາງ 5
ສ້າງແບບຈຳລອງມະຫາພາກ
ປ່ຽນກຸ່ມຕົວຊີ້ວັດທີ່ກ່ຽວຂ້ອງຂະໜາດນ້ອຍ ໃຫ້ເປັນບັດຄະແນນສະກຸນເງິນທີ່ລະບຸແຫຼ່ງທີ່ມາ.
ການທົດລອງໃຊ້ API ຂອງທ່ານເປັນເວລາ 14 ວັນ
ປ່ຽນຈາກການຮ້ອງຂໍຄັ້ງທຳອິດ ໄປສູ່ໜ້າທີ່ການງານທີ່ຄຸ້ມຄ່າທີ່ຈະຮັກສາໄວ້.
ເປົ້າໝາຍບໍ່ແມ່ນການເຂົ້າເບິ່ງທຸກໜ້າຜະລິດຕະພັນ. ແຕ່ແມ່ນການເຮັດວຽກ API ທີ່ຜ່ານການຢືນຢັນຕົວຕົນໃຫ້ສຳເລັດ, ກັບມາໃນມື້ອື່ນ, ແລະ ອອກໄປພ້ອມກັບຊຸດຂໍ້ມູນ ຫຼື ຂະບວນການເຮັດວຽກຂອງແອັບພລິເຄຊັນທີ່ເຮັດຊ້ຳໄດ້.
ວັນທີ 1-2
ເຮັດໃຫ້ຄຳຂໍມີຄວາມໜ້າເຊື່ອຖື
ແກ້ໄຂບັນຫາການຢືນຢັນຕົວຕົນ ຫຼື ບັນຫາການກັ່ນຕອງ ແລະ ປ່ຽນສະຄຣິບທຳອິດໃຫ້ເປັນວຽກທີ່ຕັ້ງຊື່ໄດ້ ແລະ ເຮັດຊ້ຳໄດ້.
ເປີດຂັ້ນຕອນ →ວັນທີ 3-4
ເພີ່ມເວລາການປ່ອຍຂໍ້ມູນ
ໃຊ້ປະຕິທິນເປັນ endpoint ຕະກູນທີສອງ ແລະ ກຳນົດເວລາການເຮັດວຽກຂອງ API ທີ່ມີປະໂຫຍດຄັ້ງຕໍ່ໄປ.
ເປີດຂັ້ນຕອນ →ວັນ 5-7
ສ້າງຜົນລັດການວິໄຈ
ເພີ່ມຄວາມຄາດຫວັງ ຫຼື ກຸ່ມສರಣະ macro ຂະໜາດນ້ອຍ, ຈາກນັ້ນສ້າງການປຽບທຽບ, ຕາຕະລາງ, ຫຼື ໃບຄະແນນທີ່ບັນທຶກໄວ້ໜຶ່ງລາຍການ.
ເປີດຂັ້ນຕອນ →ວັນ 8-10
ເຮັດໃຫ້ການອັບເດດເປັນອັດຕະໂນມັດ
ເລືອກ REST, SSE, ຫຼື webhooks ທີ່ກຳນົດເວລາໄວ້ ແລະ ສຳເລັດການລັນ API ທີ່ສຳເລັດອີກຄັ້ງໃນວັນອື່ນ.
ເປີດຂັ້ນຕອນ →ວັນທີ 11-13
ເຮັດໃຫ້ client ແຂງແຮງຂຶ້ນ
ເພີ່ມການກຳນົດເວລາໝົດອາຍຸ, ການລອງໃໝ່ແບບຈຳກັດ, ການກວດສອບການຕອບສະໜອງ, ການບັນທຶກປ້ຳທີ່ປອດໄພ, ແລະ ການຕິດຕາມຂໍ້ມູນທີ່ເກົ່າ.
ເປີດຂັ້ນຕອນ →ວັນ 14
ທົບທວນຫຼັກຖານ
ຢືນຢັນວ່າ API ໃຫ້ວຽກທີ່ສາມາດເຮັດຊ້ຳໄດ້ທີ່ທີມຂອງທ່ານຈະຮັກສາໄວ້, ຈາກນັ້ນເລືອກຊຸດຂໍ້ມູນ ຫຼື workflow ຂອງແອັບພລິເຄຊັນຖັດໄປ.
ເປີດຂັ້ນຕອນ →Request help
ວິເຄາະການຕອບສະໜອງທີ່ລົ້ມເຫຼວ ຫຼື ວ່າງເປົ່າ
Inspect the status and a short error body, then follow the matching fix. Never paste an API key or a full authenticated URL into a support message.
ຕົວຢ່າງທີ່ໃຊ້ງານໄດ້
ເກັບຮັກສາຄີຂອງທ່ານໃນ FXMD_API_KEY; ຫ້າມວາງມັນລົງໃນ source control ໂດຍເດັດຂາດ.
import os
import requests
key = os.getenv("FXMD_API_KEY", "").strip()
if not key:
raise RuntimeError("FXMD_API_KEY is not set")
response = requests.get(
"https://api.fxmacrodata.com/v1/announcements/eur/inflation",
params={"api_key": key, "limit": 1},
timeout=20,
)
print(response.status_code, response.text[:300])ຜົນລັດທີ່ຄາດໄວ້: A 200 confirms the key and path work. A 401 or 403 points to authentication or access, a 404 to the path, and a 429 to request pacing.
ເມື່ອສະຄຣິບທຳອິດກາຍເປັນລະບົບທີ່ໃຊ້ງານຈິງ
ການແກ້ໄຂບັນຫາ ແລະ ຄຳແນະນຳການຜະລິດ
ໃຊ້ຄູ່ມືເຫຼົ່ານີ້ເມື່ອການຕອບສະໜອງລົ້ມເຫຼວ, ບໍ່ມີຂໍ້ມູນສົ່ງກັບມາ, ຫຼື ຕ້ອງການການຄວບຄຸມລະດັບ production ເຊັ່ນ: caching, timeouts, retries, ແລະ event delivery.
| ຄູ່ມື | ໃຊ້ວ່າມັນເມື່ອ | ເລີ່ມຕົ້ນ |
|---|---|---|
| ວິເຄາະການຕອບສະໜອງທີ່ລົ້ມເຫຼວ ຫຼື ວ່າງເປົ່າ | ແຍກບັນຫາການຢືນຢັນຕົວຕົນ, ການເຂົ້າເຖິງ, ເສັ້ນທາງ, ຂໍ້ຈຳກັດອັດຕາ, ແລະ ຄວາມພ້ອມຂອງຂໍ້ມູນ ໂດຍບໍ່ຕ້ອງເປີດເຜີຍຄີຂອງທ່ານ. | ເປີດຄູ່ມື → |
| ເຮັດໃຫ້ຄລາຍເອນ API ພ້ອມສຳລັບການຜະລິດ | ເພີ່ມ timeouts, ການລອງໃໝ່ແບບຈຳກັດ, ການເຮັດ caching, ການຮ້ອງຂໍແບບມີເງື່ອນໄຂ, ແລະ ຮູບແບບການສົ່ງຂໍ້ມູນທີ່ຖືກຕ້ອງ. | ເປີດຄູ່ມື → |