คู่มือนักพัฒนา
สร้างเครื่องมืออัตโนมัติการสร้างลิงก์ของคุณด้วย BlogDrip API
เชื่อมต่อซอฟต์แวร์ของคุณกับ BlogDrip โดยตรงแล้วอัตโนมัติการสั่งบทความรับเชิญ สร้างเวิร์กโฟลว์ SEO แบบกำหนดเอง ผสานรวมกับแอปที่ใช้อยู่ และจัดการการดำเนินงานการสร้างลิงก์ได้มีประสิทธิภาพมากขึ้น
ทำไมต้องอัตโนมัติ
เหตุผลในการสร้างเครื่องมืออัตโนมัติสำหรับการสร้างลิงก์ของคุณเอง
เอเจนซี SEO และทีมการตลาดภายในองค์กรมักเจอรูปแบบการทำงานเหมือนกัน: ค้นหาโอกาสเผยแพร่อย่างเป็นมือ ทำการกรอกคำสั่งสั่งบทความรับเชิญซ้ำแล้วซ้ำเล่า สลับแคมเปญลูกค้าหลายรายการ โอนข้อมูลระหว่างระบบภายใน ตรวจสอบความคืบหน้าคำสั่ง และพยายามขยายงานทั้งหมดนี้โดยไม่เพิ่มจำนวนทีมงานตามไปด้วย
การผสานรวมผ่าน API จะดึงงานเชิงกลซ้ำซ้อนออกจากทีมของคุณและจัดการผ่านโค้ด ซอฟต์แวร์ที่คุณมีอยู่ — CRM เครื่องมือบริหารแคมเปญ หรือแดชบอร์ดที่ทีมใช้งานเป็นประจำ — จะสื่อสารกับมาร์เก็ตเพลสโดยตรง ผู้ปฏิบัติงานจะมุ่งเน้นที่กลยุทธ์ บรีฟ และการควบคุมคุณภาพ แทนการป้อนคำสั่งสั่งซื้อด้วยมือ
การอัตโนมัติช่วยเพิ่มประสิทธิภาพเวิร์กโฟลว์ ไม่ได้รับประกันอันดับ SEO มันจะไม่ทำให้แคมเปญที่ไม่ดีประสบความสำเร็จ และจะไม่มาแทนการตัดสินใจของมนุษย์ในการเลือกผู้เผยแพร่ สิ่งที่มันทำได้ดีคือการตัดชั้นการป้อนข้อมูลออกไป ดังนั้นเมื่อคุณตัดสินใจจะซื้อ คุณสามารถดำเนินการได้ในปริมาณใดก็ได้
สิ่งที่คุณสามารถสร้างได้
สิ่งที่คุณสามารถสร้างด้วย BlogDrip API
รูปแบบเชิงปฏิบัติสำหรับซอฟต์แวร์ที่สร้างบนการผสานรวมมาร์เก็ตเพลสผ่านโปรแกรม
แดชบอร์ดโพสต์รับเชิญแบบกำหนดเอง
แอปภายในที่เชื่อมต่อกับ BlogDrip และส่งคำสั่งสั่งบทความรับเชิญที่รองรับจาก UI ที่ทีมคุณควบคุมได้
ระบบจัดการเอเจนซี SEO
การสั่งบทความรับเชิญถูกรวมเข้าในเวิร์กโฟลว์เอเจนซีที่มีอยู่ เพื่อให้ผู้จัดการแคมเปญไม่ต้องออกจากระบบที่ใช้งานอยู่
การส่งคำสั่งซื้ออัตโนมัติ
คำขอ API สร้างคำสั่งซื้อบทความรับเชิญที่รองรับเป็นชุด โดยไม่ต้องมีขั้นตอนการป้อนข้อมูลด้วยมือสำหรับแต่ละคำสั่ง
การจัดการแคมเปญลูกค้า
เชื่อมระเบียนลูกค้าและแคมเปญภายในกับเวิร์กโฟลว์การสั่งซื้อของ BlogDrip — แหล่งข้อมูลเดียวเพื่อระบุว่าใครซื้ออะไร
อัตโนมัติของเวิร์กโฟลว์
ทริกเกอร์การดำเนินการ API ที่รองรับจากกระบวนการธุรกิจภายใน — การอนุมัติ การเริ่มงาน คลื่นแคมเปญที่ตั้งเวลาไว้
การรายงานและการติดตาม
ดึงข้อมูลที่เกี่ยวข้องกับคำสั่งเข้าเครื่องมือรายงานแบบกำหนดเองที่รองรับ ขอบเขตการรายงานควรกำหนดตามข้อมูลที่ API เปิดเผยจริง แทนการสมมติว่ามองเห็นทุกอย่างแบบเรียลไทม์
สถาปัตยกรรม
ตัวอย่างสถาปัตยกรรมการอัตโนมัติ
การผสานรวมที่ดีจะแยกหน้าที่งานออกเป็นสี่ชั้นอย่างชัดเจน
ด้านบนสุดคือแอปพลิเคชันอัตโนมัติภายนอกของคุณ — แดชบอร์ดแบบกำหนดเอง ซอฟต์แวร์เอเจนซี SEO CRM ภายใน หรือระบบจัดการแคมเปญ นี่คือที่ที่ทีมของคุณทำงานทุกวัน
ด้านล่างเป็นแบ็กเอนด์ของแอปพลิเคชันของคุณ ความรับผิดชอบของมันคือสิ่งที่การผสานรวมทุกตัวต้องทำให้ถูกต้อง: เก็บ `x-client-id` และ `x-client-secret` อย่างปลอดภัย ตรวจสอบข้อมูลนำเข้าให้เรียบร้อยก่อนจะส่งถึง BlogDrip เตรียมและส่งคำขอ API จัดการการตอบกลับ `{ data, pagination }` บันทึกเหตุการณ์ปฏิบัติการ และจัดการการลองใหม่อย่างปลอดภัยเพื่อไม่ให้ปัญหาเครือข่ายชั่วคราวกลายเป็นคำสั่งซื้อที่ถูกเรียกเก็บสองครั้ง
จากนั้นคำขอจะไปถึง BlogDrip Advertiser API — พื้นที่สาธารณะที่มีเวอร์ชันภายใต้ `/api/public/*` — ซึ่งเปิดเผยฟังก์ชันการสั่งบทความรับเชิญที่รองรับ
API จะส่งคำสั่งเข้าไปในมาร์เก็ตเพลสของ BlogDrip — มากกว่า 275,000+ เว็บไซต์ในสต็อกทั้งหมด — และจากที่นั่นเข้าสู่กระบวนการประมวลผลคำสั่งและเวิร์กโฟลว์การเผยแพร่ที่สอดคล้องกัน ขึ้นกับเว็บไซต์ที่เลือก การเผยแพร่อาจเป็นแบบแมนนวลที่ฝั่งผู้เผยแพร่ หรืออัตโนมัติผ่านปลั๊กอิน WordPress หรือ Agency API ไม่ใช่ทุกเว็บไซต์ในมาร์เก็ตเพลสจะรองรับการเผยแพร่ทันที ดังนั้นการผสานรวมของคุณจึงควรมองเวลาในการเผยแพร่ว่าเป็นเรื่องของเวิร์กโฟลว์ ไม่ใช่เกิดขึ้นทันที
สร้างเครื่องมืออัตโนมัติของคุณ ทีละขั้น
แปดขั้นตอนตั้งแต่การกำหนดขอบเขตถึงการติดตาม ใช้มันเป็นแนวทาง ไม่ใช่ลำดับบังคับ — หลายขั้นตอนทำพร้อมกันได้
กำหนดเวิร์กโฟลว์อัตโนมัติของคุณ
ระบุงานที่ควรอัตโนมัติ ข้อมูลที่แอปของคุณต้องการ เวลาในการส่งคำสั่ง วิธีป้องกันคำสั่งซ้ำ วิธีจัดการข้อผิดพลาด และวิธีเก็บข้อมูลแคมเปญ ตัวอย่างการกำหนดขอบเขตที่ชัดเจน: เอเจนซีที่ดูแล 20 ลูกค้า แต่ละรายมีแคมเปญที่ใช้งาน 3–5 รายการ ต้องการให้เมื่อมีแคมเปญใหม่ สร้างคำสั่งอัตโนมัติสำหรับรายการเว็บไซต์ที่อนุมัติล่วงหน้า — แต่ต้องเกิดขึ้นก็ต่อเมื่อมนุษย์อนุมัติบรีฟแคมเปญก่อน
ขอสิทธิ์เข้าถึง BlogDrip API
เปิดบัญชีของคุณที่ app.blogdrip.com/settings แล้วไปที่ การตั้งค่าของฉัน → การเข้าถึง API เพื่อหาข้อมูลรับรอง คุณจะเห็นสองค่าคือ `x-client-id` และ `x-client-secret` ความลับจะแสดงเพียงครั้งเดียวเมื่อออกหรือหมุนเวียน ดังนั้นคัดลอกไปยังตัวจัดการความลับของคุณทันที การเข้าถึงต้องมีการใช้จ่ายรวมขั้นต่ำ €500 ต่อเดือน — คำสั่งแบบแมนนวลนับ คำสั่งผ่าน API นับ ทั้งสองช่องทางรวมกัน การเข้าถึง API จะถูกปิดอัตโนมัติหากไม่ถึงขั้นต่ำในเดือนนั้น €500 เป็นเกณฑ์การใช้จ่าย ไม่ใช่ค่าบริการสมัครสมาชิก API แยกต่างหาก
อ่านเอกสาร API
เอกสารอย่างเป็นทางการที่ app.blogdrip.com/api/public/docs/index.html อธิบาย endpoint ที่อยู่ภายใต้ namespace `/api/public/*` อย่างชัดเจน การยืนยันตัวตน (คู่หัวข้อ header ทั้งสองที่กล่าวไปข้างต้น) วิธีการขอ ข้อกำหนดพารามิเตอร์ รูปแบบการตอบกลับ (endpoint แบบรายการจะห่อด้วย `{ data, pagination }` และใช้การแบ่งหน้าแบบ 0-based `?page=0`) ข้อผิดพลาดการตรวจสอบความถูกต้อง (`{ message }`) และการดำเนินการสั่งซื้อที่มีให้ ใช้เอกสารเป็นแหล่งข้อมูลอ้างอิง: หากพารามิเตอร์ไม่ได้ระบุในเอกสาร อย่าสมมติว่ามี
สร้างการเชื่อมต่อ API
สร้างแบ็กเอนด์แอปที่เก็บ `x-client-id` และ `x-client-secret` อย่างปลอดภัย (ตัวแปรสภาพแวดล้อม ตัวจัดการความลับ — ห้ามเก็บในโค้ดฝั่งหน้า) ส่งคำขอที่ยืนยันตัวตนโดยตั้ง header ทั้งสอง วิเคราะห์การตอบกลับ จัดการข้อผิดพลาด และเขียนล็อกเชิงโครงสร้างสำหรับการเรียกออกทุกครั้ง เก็บ client ของ API เป็นโมดูลเล็กที่ทดสอบดี เพื่อให้ส่วนที่เหลือของแอปไม่ต้องคุยกับ BlogDrip โดยตรง
ใช้งานระบบสั่งบทความรับเชิญอัตโนมัติ
เชื่อมเวิร์กโฟลว์ภายในของคุณกับการดำเนินการสั่งซื้อที่ BlogDrip รองรับ โฟลว์ทั่วไป: สร้างแคมเปญใหม่ในระบบของคุณ → เลือกเว็บไซต์ (แกะ `marketSiteId` จาก endpoint ของมาร์เก็ตเพลส) → แอปของคุณเตรียมข้อมูลคำสั่งที่จำเป็น (หัวข้อ URL คำอธิบาย `categoryId`, `marketSiteId`, `campaignId`, `scheduleDate` (ถ้ามี), `linkNoFollow`) → แบ็กเอนด์ตรวจสอบคำสั่งตามกฎธุรกิจของคุณ → แอปส่งคำสั่งผ่าน Advertiser API → เก็บการตอบกลับลงระบบของคุณเพื่อการติดตาม ตรวจสอบทุกฟิลด์ตามสเปก OpenAPI ก่อนส่งใช้งาน
จัดการข้อผิดพลาดและคำสั่งซ้ำ
ตรวจสอบคำขอก่อนส่ง ป้องกันคำสั่งซ้ำโดยไม่ตั้งใจ (การใช้คีย์ idempotency หรือการตรวจสอบ de-duplication ฝั่งเซิร์ฟเวอร์เป็นรูปแบบที่ปลอดภัย) บันทึกเหตุการณ์ความล้มเหลวของ API ทุกครั้งพร้อมบริบทเพียงพอสำหรับการดีบักภายหลัง จัดการปัญหาการเชื่อมต่อชั่วคราวอย่างนุ่มนวล และเคารพข้อจำกัดอัตราการเรียกที่ระบุ กฎสำคัญข้อหนึ่งที่ต้องยึดถือ: ห้ามลองใหม่อัตโนมัติสำหรับคำขอสร้างคำสั่งที่ไม่ idempotent โดยไม่มีการยืนยันจากมนุษย์หรือระบบ — การลองใหม่ของคำสั่งที่สำเร็จแต่คุณไม่ได้เห็นการตอบกลับ จะก่อให้เกิดการเรียกเก็บสองครั้ง
ทดสอบการผสานระบบของคุณ
รันการผสานรวมกับสภาพแวดล้อม sandbox หากมีระบุในเอกสาร หากไม่มี sandbox ให้ทดสอบกับ production อย่างระมัดระวัง — ห้ามรันชุดทดสอบอัตโนมัติที่สร้างคำสั่งจ่ายจริงโดยไม่มีการอนุญาตเฉพาะ ใช้แคมเปญทดสอบเฉพาะที่มีการตรวจสอบโดยมนุษย์ก่อนคำสั่งอัตโนมัครายแรก และจำกัดการรันทดสอบอัตโนมัติไว้กับรายการเว็บไซต์ที่คุณอนุมัติล่วงหน้าเท่านั้น
ปรับใช้และติดตาม
ย้ายข้อมูลรับรองไปยังที่เก็บความลับสำหรับโปรดักชัน เพิ่มการมอนิเตอร์สำหรับความล้มเหลวของการผสานรวมและรูปแบบการส่งคำสั่งที่ผิดปกติ ติดตามผลการส่งคำสั่งตั้งแต่ต้นจนจบ เก็บล็อกปฏิบัติการไว้นานพอที่จะดีบักเหตุการณ์ย้อนหลังสองสัปดาห์ ตรวจสอบการใช้จ่ายในบัญชีของคุณเพื่อไม่ให้เสียการเข้าถึง API เมื่อตกต่ำกว่า €500 ต่อเดือน และเฝ้าดู changelog ของ BlogDrip สำหรับการอัปเดต API ที่อาจต้องการการบำรุงรักษาการผสานรวม
รูปแบบการผสานระบบ
ลักษณะการผสานระบบที่ดี
แหล่งข้อมูลที่เชื่อถือได้สำหรับตัวอย่างที่ใช้งานได้จริงคือสเปก OpenAPI ที่ app.blogdrip.com/api/public/openapi.json และเอกสารที่อ่านได้สำหรับมนุษย์ที่ /api/public/docs สเปกคือสิ่งที่โค้ดของคุณควรถูกสร้างหรือทดสอบเทียบกับ — ไม่ใช่สเนิปเพ็ตบนหน้า landing page ที่อาจล้าสมัย
ในการปฏิบัติ การผสานรวมที่เรียบร้อยมักมีรูปแบบเดียวกัน โมดูล client API บาง ๆ ในภาษาที่คุณชอบ — ฟังก์ชัน wrapper หนึ่งชิ้นต่อการดำเนินการที่คุณต้องการ — จะดูแลกลไก: ตั้ง header `x-client-id` และ `x-client-secret` ในทุกคำขอ ลำเลียงร่างกายคำขอ แปลงซ้อน封 `{ data, pagination }` สำหรับ endpoint แบบรายการ (การแบ่งหน้า 0-based) และแปลงการตอบกลับข้อผิดพลาด (`{ message }`) เป็น exception ที่ธุรกิจของคุณสามารถจับได้อย่างสะอาด แต่ละ wrapper ควรมีอย่างน้อยหนึ่งเทสต์ที่ตรวจสอบรูปร่างตามที่เอกสารระบุ เพื่อให้การเปลี่ยนแปลงสคีมาแสดงเป็นเทสต์ล้มเหลวก่อนถึง production หลังจากโมดูลนั้นเสถียรแล้วค่อยเชื่อมเข้ากับส่วนที่เหลือของแอป — ทริกเกอร์แคมเปญ คิวคำสั่ง คนทำงานลองใหม่ รายงาน
ลำดับนี้ช่วยให้การผสานรวมตรวจสอบได้: API client ของคุณเป็นพื้นที่ผิวขนาดเล็กที่ทดสอบดี ทุกอย่างที่เหลือสื่อสารกับ BlogDrip ผ่านมัน
แนวปฏิบัติที่ดีที่สุด
สิ่งที่ทำให้การผสาน API ยั่งยืน
รูปแบบที่ทำให้ระบบอัตโนมัติยังคงทำงานได้ดีนานหลังวันเปิดใช้งาน
ออกแบบให้ไม่ทำซ้ำ
มองว่าการสร้างคำสั่งซื้อมีค่าและไม่สามารถย้อนกลับได้ ลดความซ้ำซ้อนที่ฝั่งคุณก่อนส่งคำขอ — อย่ารอให้เกิดขึ้นหลังจากนั้น
การดูแลข้อมูลรับรอง
ข้อมูลรับรอง API ควรอยู่ในตัวจัดการความลับ แยกตามสภาพแวดล้อม หมุนเมื่อผู้รับผิดชอบออกจากทีม ไม่ใช่เฉพาะเมื่อเกิดการรั่วไหล
การบันทึกแบบมีโครงสร้าง
คู่คำขอ + การตอบกลับแต่ละคู่ควรมี correlation ID การดีบักคำสั่งเก่าจะง่ายขึ้นมากเมื่อมีบริบทที่เป็นระบบ
ไคลเอนต์ที่คำนึงถึงขีดจำกัด
เคารพขีดจำกัดการเรียกที่ระบุ ไคลเอนต์ที่ถอยกลับอย่างเหมาะสมจะขยายได้ไกลกว่าที่พึ่งทดลองลองใหม่อย่างก้าวร้าว
มีมนุษย์ตรวจสอบ
ปกป้องการเรียกใช้งานครั้งแรกบน production ด้วยการอนุมัติโดยมนุษย์ ขยายการอัตโนมัติเมื่อผสานรวมพิสูจน์แล้วว่าเสถียร
การเฝ้าติดตามการใช้จ่าย
แจ้งเตือนเมื่อการใช้จ่ายรายเดือนเข้าใกล้หรืออยู่ต่ำกว่า €500 การเสียการเข้าถึง API กลางคันของแคมเปญเป็นเรื่องที่เจ็บปวด
คำถามที่พบบ่อย
BlogDrip API ใช้สำหรับใคร?
บัญชีผู้ลงโฆษณาที่ต้องการเชื่อมซอฟต์แวร์ของตัวเอง — แดชบอร์ดแบบกำหนดเอง แพลตฟอร์มเอเจนซี SEO CRM ภายใน — เข้ากับเวิร์กโฟลว์การสั่งบทความรับเชิญของ BlogDrip ผู้ใช้ทั่วไปคือเอเจนซีที่จัดการแคมเปญจำนวนมาก ทีม SEO ภายในที่ผสานรวมกับสแตกที่มีอยู่ และนักพัฒนาที่สร้างเครื่องมือปฏิบัติการให้ลูกค้าหรือผลิตภัณฑ์เฉพาะ
ผม/ฉันต้องเป็นนักพัฒนาหรือไม่เพื่อใช้ API?
ถ้าจะสร้างการผสานรวมเอง จำเป็นต้องเป็นนักพัฒนาครับ/ค่ะ API เป็นอินเทอร์เฟซเชิงโปรแกรม — การใช้งานต้องเขียนโค้ดหรือทำงานร่วมกับนักพัฒนา หากต้องการประโยชน์ทางปฏิบัติการโดยไม่ต้องผสานรวม UI ของมาร์เก็ตเพลสก็ครอบคลุมฟังก์ชันการสั่งซื้อแบบแมนนวลอยู่แล้ว
ข้อกำหนดการเข้าถึงมีอะไรบ้าง?
ต้องมีบัญชี BlogDrip ที่มียอดใช้จ่ายรวมไม่น้อยกว่า €500 ต่อเดือน — คำสั่งแบบแมนนวลและผ่าน API ทั้งหมดย่อมถูกนับรวม การเข้าถึง API จะถูกปิดอัตโนมัติหากบัญชีของคุณใช้จ่ายน้อยกว่าเกณฑ์ในเดือนนั้น €500 เป็นเกณฑ์ปริมาณการใช้จ่าย ไม่ใช่ค่าบริการสมัครสมาชิก API แยกต่างหาก
เอกสาร API อยู่ที่ไหน?
เอกสาร API อย่างเป็นทางการเผยแพร่ที่ app.blogdrip.com/api/public/docs/index.html โดยมีสเปก OpenAPI ที่อ่านด้วยเครื่องอยู่ที่ app.blogdrip.com/api/public/openapi.json ทั้งสองแหล่งอธิบายรูปแบบการยืนยันตัวตน แคตาล็อก endpoint ภายใต้ namespace `/api/public/*` รูปแบบคำขอและการตอบกลับ รูปแบบการแบ่งหน้า และการตอบกลับข้อผิดพลาด ให้ใช้เป็นแหล่งอ้างอิงหลักสำหรับการผสานรวมของคุณ
ฉันจะหาข้อมูลรับรอง API ได้จากที่ไหน?
ที่ การตั้งค่าของฉัน → การเข้าถึง API ใน app.blogdrip.com/settings คุณจะได้รับ `x-client-id` และ `x-client-secret` ทั้งสองต้องใส่ในทุกคำขอที่ยืนยันตัวตนเป็น HTTP header ความลับจะแสดงเพียงครั้งเดียวเมื่อออกหรือหมุนเวียน — คัดลอกไปยังตัวจัดการความลับของคุณทันที เพราะไม่สามารถดึงกลับมาได้ภายหลัง ข้อมูลรับรองเป็นต่อบัญชี; ปฏิบัติต่อมันเหมือนความลับอื่น ๆ และอย่าเก็บในระบบควบคุมเวอร์ชัน
การแบ่งหน้าบน endpoint แบบรายการทำงานอย่างไร?
endpoint แบบรายการจะห่อการตอบกลับด้วยซอง `{ data, pagination }` และใช้การแบ่งหน้าแบบ 0-based — ส่ง `?page=0` สำหรับหน้าที่หนึ่ง `?page=1` สำหรับหน้าที่สอง และต่อไปเรื่อย ๆ บล็อก pagination ในการตอบกลับจะบอกว่ามีหน้าต่อไปหรือไม่ หากคุณย้ายมาจากอินเทอร์เฟซเดิม `/api/<path>` รูปร่างการตอบกลับยังไม่เปลี่ยน — เพียงย้าย base path ไปที่ `/api/public/*`
API รองรับเว็บฮุกไหม?
ตรวจสอบสเปก OpenAPI ที่ app.blogdrip.com/api/public/openapi.json เพื่อดูรายการปัจจุบันของกลไกการเรียกกลับหรือการแจ้งเหตุการณ์ หากฟีเจอร์หนึ่งไม่ได้ระบุ ให้สร้างการผสานรวมโดยไม่สมมติว่ามี — การ polling API ตามตารางเวลาของคุณเองเป็นทางเลือกสำรองที่ปลอดภัย
มีสภาพแวดล้อม sandbox หรือไม่?
คำตอบที่เชื่อถือได้คือระบุไว้ในเอกสาร API ปัจจุบัน หากมี sandbox ให้ใช้สำหรับทดสอบการผสานรวม หากไม่มี ให้หลีกเลี่ยงการสร้างคำสั่งจ่ายจริงในระหว่างการทดสอบอัตโนมัติโดยไม่มีการอนุญาต — ใช้แคมเปญทดสอบเฉพาะและการตรวจสอบโดยมนุษย์แทน
คำสั่งผ่าน API สามารถใช้การเผยแพร่ทันที (Instant Publishing) ได้หรือไม่?
การใช้ Instant Publishing ขึ้นอยู่กับว่าเว็บไซต์ที่เลือกรองรับการผสานรวมการเผยแพร่อัตโนมัติ (ผ่านปลั๊กอิน BlogDrip WordPress หรือการเชื่อมต่อ Agency API) ใด ๆ ที่ถูกวางคำสั่ง — ผ่าน API หรือแบบแมนนวล — บนเว็บไซต์ที่มีคุณสมบัติมีโอกาสได้รับประโยชน์จากการเผยแพร่อัตโนมัติ ไม่ใช่ทุกเว็บไซต์ในมาร์เก็ตเพลสจะรองรับ ดังนั้นการผสานรวมของคุณควรมองเวลาในการเผยแพราว่าเป็นเรื่องเฉพาะเว็บไซต์ ไม่ใช่แบบเป็นมาตรฐานเดียวกันทั้งหมด
ความแตกต่างระหว่าง Advertiser API และ Agency API คืออะไร?
Advertiser API สำหรับลูกค้าที่ต้องการอัตโนมัติการสั่งบทความรับเชิญจากซอฟต์แวร์ของตนเอง Agency API สำหรับเอเจนซีภายนอก แพลตฟอร์มการสร้างลิงก์ และเครือข่ายผู้เผยแพร่ที่ต้องการเชื่อมสต็อกของตนกับ BlogDrip และอัตโนมัติการดำเนินการที่รองรับ ทั้งสองแยกจากกัน — การใช้หนึ่งไม่ได้หมายความว่าต้องใช้อีกหนึ่ง
จะเกิดอะไรขึ้นถ้าฉันลองใหม่คำขอสร้างคำสั่งที่ล้มเหลว?
หากคุณไม่ได้เห็นการตอบกลับยืนยัน ให้สมมติว่าคำขอแรกอาจสำเร็จที่ฝั่งเซิร์ฟเวอร์ อย่าลองใหม่อัตโนมัติสำหรับการสร้างคำสั่งที่ไม่ idempotent เพิ่มคีย์การลดความซ้ำซ้อนฝั่งเซิร์ฟเวอร์ หรือสอบถามว่ามีคำสั่งถูกสร้างขึ้นแล้วก่อนจะลองใหม่ — แล้วแต่ว่าเวิร์กโฟลว์ของคุณรองรับแบบไหน การลองใหม่บนคำสั่งที่สำเร็จแต่คุณไม่ได้เห็นการตอบกลับจะทำให้เกิดการเรียกเก็บซ้ำ
พร้อมอัตโนมัติการสร้างลิงก์ของคุณหรือยัง?
เปิดเอกสาร API สร้างข้อมูลรับรองของคุณ และเริ่มพัฒนา มาร์เก็ตเพลสจะขยายตามการอัตโนมัติของคุณ — ไม่ใช่ในทางกลับกัน