ConnectWiz + API اور Webhooks

فعال انٹیگریشن

جو API ہم بیچتے ہیں، وہی API ہم استعمال کرتے ہیں

پورا پلیٹ فارم ایک ہی OpenAPI معاہدے میں بیان ہوا ہے، اور ہمارا اپنا پینل اور موبائل ایپ اسی سے بنتے ہیں — نہ کوئی چھپا ہوا endpoint، نہ دستاویز کا حقیقت سے ہٹنا۔ اس کے اوپر: محدود دائرے والی Commerce API کلیدیں، محفوظ webhook ٹرگر، اور ایسے Flows جو آپ کے نظاموں کو کال کرتے ہیں۔

ایک ہی OpenAPI معاہدہ محدود دائرے والی API کلیدیں HMAC سے تصدیق شدہ webhooks
API & Webhooks × ConnectWiz
پے لوڈ ڈیٹا ہیں، کمانڈ کبھی نہیں
محدود دائرے والی کلید: کیٹلاگ پڑھنا · آرڈر لکھنا
webhook آیا ← HMAC سے تصدیق ← Flow شروع
Flow کا REST قدم آپ کے API کو کال کرتا ہے
1
ریکارڈ کا OpenAPI معاہدہ — وہی فائل جس سے ہمارا اپنا پینل اور موبائل ایپس بنتی ہیں
3
Commerce کے دائرے — کیٹلاگ پڑھنا، آرڈر پڑھنا، آرڈر لکھنا — ہر کلید کے ساتھ الگ جاری
100
ایک پڑھت میں زیادہ سے زیادہ قطاریں، سرور کی طرف سے باندھی ہوئی — limit پیرامیٹر جانچا جاتا ہے، اس پر بھروسہ نہیں کیا جاتا
50
API کے ذریعے فی آرڈر لائن آئٹم — ایک اعلان شدہ حد، دریافت شدہ نہیں

ڈیولپرز

یہ کیا کرتا ہے — بالکل ٹھیک ٹھیک

ریکارڈ کا ایک ہی معاہدہ

ایک ہی OpenAPI 3 دستاویز پورے پلیٹ فارم کو بیان کرتی ہے؛ ہمارے اپنے TypeScript کلائنٹ اسی سے بنتے ہیں — دستاویز حقیقت سے ہٹ ہی نہیں سکتی، کیونکہ حقیقت دستاویز سے بنتی ہے۔

Commerce API کی کلیدیں

ٹیننٹ کی جاری کردہ کلیدیں، صاف صاف دائروں کے ساتھ — کیٹلاگ پڑھنا، آرڈر پڑھنا، آرڈر لکھنا — آپ کا اپنا اسٹور فرنٹ یا ایپ اسی آرڈر انجن پر چلاتی ہیں، اور قیمتیں ہمیشہ سرور ہی طے کرتا ہے۔

آنے والے webhooks، محفوظ

ہر Flow کے webhook ٹرگر کا اپنا URL اور اپنی خفیہ کلید ہوتی ہے، خام body پر HMAC تصدیق، اور replay سے حفاظت۔ پے لوڈ کسی شخص کا نام لے سکتا ہے؛ Flow کے اندرونی کام کو کبھی چلا نہیں سکتا۔

باہر جانے کا راستہ Flows سے

REST قدم آپ کے نظاموں کو بالکل انہی لمحوں پر کال کرتا ہے جو آپ کینوس پر کھینچتے ہیں — آرڈر ہوا، رضامندی ملی، بکنگ ہوئی۔

تکنیکی پہلو

API کے ڈیزائن کے فیصلے، لکھ کر

قیمتیں کبھی کلائنٹ سے نہیں آتیں

آرڈر کی درخواست صرف یہ بتاتی ہے کہ کیا اور کتنا — نام اور قیمت اسی لمحے کیٹلاگ سے، سرور کی طرف پڑھی جاتی ہے اور لائن پر بطور تصویر لکھ دی جاتی ہے۔ چھیڑی ہوئی درخواست کوئی رعایت ایجاد نہیں کر سکتی۔

کال سے پہلے صلاحیتیں

ہر انٹیگریشن سطح اپنا صلاحیت کا معاہدہ شائع کرتی ہے — کیا وہ فون سے ملا سکتی ہے، مہمان آرڈر گنوا سکتی ہے، آرڈر بنا سکتی ہے؟ — اور اعلان شدہ "نہیں" سے آگے کال کرنے پر فوراً ایرر ملتا ہے، کہیں گہرائی میں جا کر ناکامی نہیں ہوتی۔

ایسے ایرر جن کا مطلب ہوتا ہے

ٹرانسپورٹ "اجازت نہیں" اور "سروس بند" میں فرق کرتا ہے — سو "دکان تک رسائی نہیں" کبھی "اس گاہک نے کبھی کچھ خریدا ہی نہیں" بن کر نہیں دکھتا۔ نام والے ایرر ہی API اور اندازے کے کھیل کے بیچ کا فرق ہیں۔

replay سے محفوظ webhooks

ہر آنے والا ایونٹ پروسیس ہونے سے پہلے idempotency کھاتے میں اپنی منفرد کلید رجسٹر کرتا ہے — دوبارہ بھیجی یا دہرائی گئی ڈیلیوری ڈیٹابیس کی سطح پر ہی ختم ہو جاتی ہے، آپ کی آٹومیشن میں نہیں۔

کلیدیں hash شدہ، خفیہ کلیدیں دائرے میں

API کلیدیں hash کی صورت میں محفوظ ہوتی ہیں اور دروازے پر صرف hash اور دائرے ہی پڑھے جا سکتے ہیں — لیک ہو جانے والی ڈیٹابیس قطار نہ کسی ورک اسپیس کا نام دیتی ہے، نہ اپنے دائرے سے باہر کچھ کھولتی ہے۔

ڈرافٹ اور تصدیق، دونوں صاف صاف

آرڈر بناتے وقت ایک صاف confirm پیرامیٹر لیا جاتا ہے — عوامی API طے شدہ طور پر تصدیق شدہ مانتا ہے، پینل کے Flows ڈرافٹ رکھ سکتے ہیں — سو "کیا یہ اصلی ہے؟" ایک فیلڈ ہے، کوئی رواج نہیں۔

سیٹ اپ

یہ کیسے جڑتا ہے

01

کلید جاری کرنا

پینل میں محدود دائرے والی Commerce API کلید بنائیں؛ اور اتنی ہی آسانی سے منسوخ کر دیں۔

02

webhook جوڑنا

webhook ٹرگر والا ایک Flow بنائیں؛ درخواستوں پر اسی کی خفیہ کلید سے دستخط کریں۔

03

باہر واپس کال کرنا

جہاں آپ کے نظاموں کو خبر ملنی چاہیے، وہاں REST قدم شامل کر دیں۔

ساتھ بہتر

کس کے ساتھ مل کر چلتا ہے

Flows

webhook ٹرگر انہیں شروع کرتے ہیں: Flows؛ اور REST قدم آپ کے نظاموں کو انہی لمحوں پر واپس کال کرتے ہیں جو آپ کینوس پر کھینچتے ہیں — اندر آنے والی اور باہر جانے والی آٹومیشن، دونوں کا کینوس ایک ہی ہے۔

Commerce

یہی کیٹلاگ اور آرڈر انجن API کے پیچھے ہے، اور چیٹ شاپ اور مصنوعی ذہانت بھی یہی استعمال کرتے ہیں — آرڈر کی ایک ہی سچائی، چار دروازے۔

آپ کا اپنا اسٹور فرنٹ

ٹیمیں آج Commerce API پر headless اسٹور فرنٹ چلا رہی ہیں — یہ وہی راستہ ہے جس کی سفارش Shopify کا صفحہ بغیر لگی لپٹی کرتا ہے، جب تک مقامی کنیکٹر بن رہا ہے۔

تحفظ اور ضمانتیں

بورنگ ضمانتیں

خام body پر HMAC

webhook کی تصدیق خام درخواست body پر فی ٹرگر خفیہ کلید سے دستخط کرتی ہے اور مستقل وقت میں ملاتی ہے — پڑھنا ثبوت ملنے کے بعد ہی شروع ہوتا ہے۔

پے لوڈ ڈیٹا ہیں، کمانڈ کبھی نہیں

webhook کا پے لوڈ کسی شخص کا حوالہ دے سکتا ہے؛ وہ کبھی Flow کے اندرونی کام کو نہیں چلا سکتا، نہ پرامپٹ بدل سکتا ہے، نہ ٹولز چلا سکتا ہے۔ ڈیٹا اور ہدایات کے بیچ کی حد ڈھانچے میں بنی ہے، رویے میں نہیں۔

ہر دروازے پر رفتار کی حد

عوامی endpoints معیاری throttling پر چلتے ہیں، اور پڑھنے کی حدیں سرور کی طرف باندھی جاتی ہیں — بدتمیزی کرنے والا کلائنٹ اپنا ہی نقصان کرتا ہے، پلیٹ فارم کا نہیں۔

باریک حروف، بغیر لگی لپٹی

حدود، صاف صاف لکھی ہوئی

ابھی کوئی فائر ہوز نہیں

سب کچھ سننے والی عام webhook فیڈ ابھی نہیں بنی — باہر جانے والے ایونٹ آج Flow کے قدموں سے ہوتے ہیں۔ یہ بات یہیں لکھ دی ہے، تاکہ کسی فروخت کی کال میں اس کے برعکس اشارہ نہ دینا پڑے۔

پڑھت کی حد، ڈیزائن ہی سے

ایک پڑھت زیادہ سے زیادہ 100 قطاریں لوٹاتی ہے، cursor کے ساتھ — یہ API عملی انٹیگریشن کے لیے بنا ہے، بڑے پیمانے پر برآمد کے لیے نہیں۔ بڑے پیمانے کی ضرورت ایک گفتگو ہے، کوئی چور دروازہ نہیں۔

API اور Webhooks سے متعلق سوالات

سیدھے جواب

مزید تفصیل یہاں ہے: عام سوالات، یا ہم سے براہ راست پوچھیں۔

پلیٹ فارم ایک ہی OpenAPI 3 معاہدے میں بیان ہوا ہے — وہی فائل جس سے ہمارا ویب پینل اور موبائل ایپ اپنی types بناتے ہیں۔ جس چیز سے آپ جڑتے ہیں، ہم خود بھی اسی پر چلتے ہیں۔

فی ٹرگر الگ خفیہ کلید، خام body پر HMAC تصدیق، اور idempotency کھاتے کے ذریعے replay سے حفاظت۔ اور اصول یہ ہے کہ پے لوڈ ڈیٹا ہے: وہ کسی شخص کا حوالہ دے سکتا ہے، آٹومیشن کو حکم کبھی نہیں دے سکتا۔

Flow کے REST قدموں کے ذریعے، انہی لمحوں پر جو آپ کینوس پر چنتے ہیں۔ باہر جانے والی عام webhook فیڈ روڈ میپ پر ہے اور آنے سے پہلے جان بوجھ کر اس کا وعدہ نہیں کیا جاتا۔

ہاں — کیٹلاگ پڑھنا اور آرڈر لکھنا، یہی سہارا دیا گیا راستہ ہے، قیمتیں سرور طے کرتا ہے اور کلیدیں محدود دائرے والی ہیں جنہیں آپ ہر سطح کے لیے الگ منسوخ کر سکتے ہیں۔ 50 لائن اور 100 قطار کی حدیں اسی لیے لکھ دی گئی ہیں کہ آپ انہیں سامنے رکھ کر ڈیزائن کریں، ان سے ٹکرائیں نہیں۔

ہماری طرف ڈیلیوری idempotent ہے — کھاتہ دہرائی گئی ڈیلیوری پہچان کر گرا دیتا ہے، سو آپ کے نظام بے فکر ہو کر دوبارہ بھیج سکتے ہیں۔ Flows سے باہر جانے والے REST قدموں کی اپنی retry پالیسی ہے، اور ناکامیاں Flow کے چلنے کے ریکارڈ پر دکھائی دیتی ہیں۔

ایمانداری سے جڑنا، شور مچا کر جڑنے سے بہتر ہے۔

یہاں ہر انٹیگریشن اسی سے بیان ہوا ہے جو وہ واقعی کرتا ہے — سمت، ملکیت اور حدود سمیت۔