انٹیگریشنز اسپیسیفیکیشن

ہر انٹیگریشن کا معاہدہ اور پلیٹ فارم انٹیگریشن لیئر (API، ویب ہوکس، SSO) جو سندھ آئی ٹی پورٹل — سہولت ڈیسک (SITP) کو حکومتی رجسٹریوں، مواصلات فراہم کنندگان، ویڈیو پلیٹ فارمز، اور پارٹنر کنزیومرز سے جوڑتا ہے۔

فیلڈ	قدر
دستاویز آئی ڈی	08
حیثیت	ڈرافٹ
مالک	S&ITD / MAAHIR
زبانیں	EN (master) · UR · SD
متعلقہ دستاویزات	`/specs/ur/15-tech-architecture/`، `/specs/ur/12-api-contract/`، `/specs/ur/11-security-compliance/`، `03-non-functional-requirements/en.md`، `/specs/ur/05-data-model/`

1. دائرہ کار اور اس دستاویز کو پڑھنے کا طریقہ

یہ دستاویز ہر بیرونی نظام سے جس سے SITP بات چیت کرتا ہے اور ہر بیرونی سطح جو اس کی نمائش کرتا ہے کے لیے مستند معاہدہ ہے۔ اس میں شامل ہیں:

انٹیگریشن لیئر خود — وہ تعمیراتی پیٹرن جس کی ہر ایڈاپٹر پابندی کرتا ہے (§2)۔
وہ انٹیگریشن ٹیمپلیٹ جس کے ذریعے ہر ایڈاپٹر کو بیان کیا جاتا ہے (§3)۔
حکومتی شناخت و رجسٹری انٹیگریشنز — NADRA، SECP، FBR، SRB، PSEB، NITB e-Office (§4)۔
مواصلات انٹیگریشنز — Mailjet، SMS گیٹ وے، WhatsApp Business API (§5)۔
ویڈیو کنفرنسنگ — Zoom، Google Meet، Microsoft Teams (§6)۔
شناخت و SSO — Keycloak کے ذریعے OIDC (§7)۔
پبلک API برائے پارٹنر کنزیومرز (§8)۔
ویب ہوکس — آؤٹ باؤنڈ اور اِن باؤنڈ (§9)۔
ڈیٹا میپنگ و ماسٹر ڈیٹا (§10)۔
انٹیگریشنز کے مخصوص غیر فنکشنل تقاضے (§11)۔
انٹیگریشن روڈ میپ اور منحصریات (§12)۔

تکنیکی اسٹیک اور اعلیٰ سطحی فن تعمیر _context.md §3 میں مقفل ہیں اور /specs/ur/15-tech-architecture/ §13 میں تفصیلی ہیں۔ یہ دستاویز ٹیک آرکیٹیکچر کے §13 کو ہر انٹیگریشن کے معاہدے میں پھیلاتی ہے۔ جہاں یہ دستاویز اور ٹیک آرکیٹیکچر میں اختلاف ہو، ٹیک آرکیٹیکچر پلیٹ فارم کے لیے سرچ سم起动 اور یہ دستاویز انفرادی انٹیگریشن معاہدوں کے لیے سرچ سماء ہے۔

2. انٹیگریشن فن تعمیر

ہر بیرونی نظام — حکومتی رجسٹری، مواصلات فراہم کنندہ، ویڈیو پلیٹ فارم، پارٹنر کنزیومر — تک رسائی صرف NestJS Integrations ماڈیول کے اندر ایک ایڈاپٹر کے ذریعے ہوتی ہے۔ Integrations کے باہر کوئی بھی ماڈیول وینڈر SDK امپورٹ نہیں کرتا، براہ راست وینڈر HTTP اینڈ پوائنٹ کال نہیں کرتا، یا وینڈر کریڈینشل نہیں پڑھتا۔ یہ نظام کی اینٹی کرپشن (anti-corruption) سرحد ہے: یہ SITP کی ڈومین زبان اور ڈیٹا ماڈل کو ہر بیرونی نظام کی عجیب و غریب خصوصیات، اسکیما تبدیلیوں، اور اسٹیج سے الگ تھلگ رکھتا ہے۔

2.1 تعمیراتی غیر متغیرات

#	غیر متغیر	نفاذ
1	ایڈاپٹر پیٹرن	ہر بیرونی نظام کا بالکل ایک ایڈاپٹر ماڈیول ہے جو ایک مستحکم اندرونی انٹرفیس کو نافذ کرتا ہے۔ تمام کال سائٹس انٹرفیس کے لیے پروگرام کرتے ہیں، کبھی SDK کے لیے نہیں۔
2	اینٹی کرپشن لیئر	ایڈاپٹرز بیرونی پے لوڈز کو SITP ڈومین آبجیکٹس میں اور واپس ترجمہ کرتے ہیں۔ بیرونی فیلڈ نام کبھی ایڈاپٹر سے آگے لیک نہیں ہوتے۔
3	خفیہ چیزیں والٹ میں	کریڈینشلز، API کلیدز، سائننگ سیکیٹس، اور OAuth کلائنٹ سیکیٹس خفیہ والٹ میں رہتے ہیں (دیکھیں `/specs/ur/15-tech-architecture/` §16)، اسٹارٹ اپ پر حاصل کیے جاتے ہیں، §11.7 کے مطابق روٹیٹ ہوتے ہیں۔ کوئی بھی راز کبھی ریپو میں کمٹ نہیں ہوتا یا سادہ env فائل سے پڑھا نہیں جاتا۔
4	آئی ڈیمپوٹنسی کلیدز	ہر آؤٹ باؤنڈ حالت تبدیل کرنے والی کال ایک آئی ڈیمپوٹنسی کلید رکھتی ہے (`Idempotency-Key` ہیڈر یا وینڈر متبادل)۔ ایڈاپٹر اور ریموٹ سسٹم اس کی پابندی کرتے ہیں تاکہ دوبارہ کوششیں کبھی دو بار نہ لکھیں۔
5	ریٹریز exponential backoff + jitter کے ساتھ	عارضی ناکامیوں کی ریٹری کیپڈ exponential backoff اور بے ترتیب jitter کے ساتھ ہوتی ہے؛ زیادہ سے زیادہ کوششیں اور ڈیڈ لیٹر کیو مستقل ناکام کالوں کو پکڑتے ہیں۔
6	ہر ایڈاپٹر کے لیے سرکٹ بریکرز	ہر ایڈاپٹر کا اپنا بریکر ہے (جیسے، Opossum)۔ ٹرپڈ بریکر بیرونی اسٹیج کے دوران کنکشنز کو جمع کیے بغیر فوری فیل ہوتا ہے۔
7	ڈیڈ لیٹر کیو (DLQ)	جو کالیں ریٹریز ختم کر لیتی ہیں وہ BullMQ/Redis میں فی ایڈاپٹر DLQ میں جاتی ہیں؛ آپس وہاں سے ٹرائیج اور ری پلے کرتا ہے۔
8	ہر کال کا آڈٹ	ہر آؤٹ باؤنڈ کال اور ہر اِن باؤنڈ ویب ہوک پے لوڈ کو (حساس فیلڈز حذف شدہ) `int_call` ٹیبل میں ریکارڈ کیا جاتا ہے، سمت، ایڈاپٹر، ہدف، لیٹینسی، حیثیت، اور حذف شدہ پے لوڈ اقتباس کے ساتھ۔
9	سست/بیرونی کام کے لیے قطار	کوئی بھی کال جو تخمینہًا > 250 ms ہو یا جو اعتماد کی سرحد پار کرے، BullMQ میں قطار میں لگائی جاتی ہے، کبھی بھی کسی درخواست میں اِن لائن نہیں چلائی جاتی۔
10	فیچر فلگڈ	ہر ایڈاپٹر ایک فیچر فلگ کے پیچھے ہوتا ہے تاکہ اسے ری ڈیپلائے کے بغیر فی ماحول/محکمہ کے مطابق غیر فعال کیا جا سکے۔

2.2 انٹیگریشن لیئر ڈایاگرام

نیچے دیا گیا ڈایاگرام ایک ڈومین ماڈیول سے انٹیگریشن لیئر کے ذریعے بیرونی نظام تک ایک واحد آؤٹ باؤنڈ کال کا رن ٹائم بہاؤ دکھاتا ہے، اور بیرونی نظاموں سے SITP میں واپس ویب ہوک ڈلیوریوں کا متعلقہ اِن باؤنڈ راستہ۔

flowchart TB subgraph Domain["NestJS domain modules"] TKT["Tickets"] ORG["Org / RBAC"] NOT["Notifications"] MTG["Meetings / TRI / MoM"] REG["Registration"] end subgraph IntLayer["Integration layer (anti-corruption)"] IFACE["Stable adapter interfaces<br/>(RegistryAdapter · CommsAdapter · VideoAdapter · ... )"] ADP["Concrete adapters<br/>(NADRA · SECP · FBR · SRB · PSEB · e-Office · Mailjet · SMS · WA · Zoom/Meet/Teams)"] RES["Resilience wrapper<br/>(idempotency · retry+backoff · circuit breaker · DLQ)"] AUD["Audit recorder → int_call"] SEC["Secrets resolver (vault)"] MAP["Data mapping / master-data lookup"] end subgraph Q["BullMQ queues"] OQ["Outbound queue (per adapter)"] DLQ["Dead-letter queue (per adapter)"] IQ["Inbound webhook queue"] end subgraph Ext["External systems"] NADRA["NADRA Verisys"] GOV["SECP · FBR · SRB · PSEB · NITB e-Office"] MJ["Mailjet"] SMS["SMS gateway"] WA["WhatsApp Cloud API"] VID["Zoom / Meet / Teams"] end subgraph Inbound["Inbound path"] HOOK["Webhook receiver<br/>(signature verify · replay protect)"] end TKT --> IFACE ORG --> IFACE NOT --> IFACE MTG --> IFACE REG --> IFACE IFACE --> ADP SEC --> ADP MAP --> ADP ADP --> RES RES --> AUD RES --> OQ OQ --> NADRA OQ --> GOV OQ --> MJ OQ --> SMS OQ --> WA OQ --> VID RES -- "exhausted" --> DLQ MJ -. "delivery/bounce webhook" .-> HOOK WA -. "inbound reply webhook" .-> HOOK GOV -. "e-Office status callback" .-> HOOK HOOK --> IQ IQ --> Domain

انٹیگریشن لیئر ڈومین ماڈیولز (جو کبھی نہیں جانتے کہ کون سا وینڈر پلگ ان ہے) اور بیرونی نظاموں کے درمیان واقع ہے۔ ایک ڈومین ماڈیول ایک مستحکم انٹرفیس جیسے RegistryAdapter.verifyCnic(...) کال کرتا ہے؛ Integrations ماڈیول کنکریٹ ایڈاپٹر (NADRA) کو ریزولو کرتا ہے، والٹ سے کریڈینشلز نکالتا ہے، ماسٹر ڈیٹا میپنگ لگاتا ہے، کال کو ریزلیئنس لیئر میں لپیٹتا ہے (آئی ڈیمپوٹنسی کلید → ریٹری → سرکٹ بریکر → DLQ)، ایک آڈٹ قطار ریکارڈ کرتا ہے، اور اصل HTTP/SDK کال BullMQ ورکر سے بھیجتا ہے۔ یہی طبعی لیئر اِن باؤنڈ ویب ہوکس بھی قبول کرتا ہے: ویب ہوک وصول کنندہ دستخط کی تصدیق کرتا ہے، ری پلےز مسترد کرتا ہے، ایک نارمالائزڈ ایونٹ کو قطار میں لگاتا ہے، اور ایک ورکر اسے مناسب ڈومین ماڈیول میں بھیجتا ہے۔ DLQ ہر اس کال کو پکڑتا ہے جو ریٹری بجٹ کے اندر مکمل نہیں ہو سکتا تاکہ آپس ٹرائیج اور ری پلے کر سکے۔

2.3 ایڈاپٹر انٹرفیس (تمثیلی)

ہر ایڈاپٹر خاندان ایک چھوٹا، مستحکم انٹرفیس نافذ کرتا ہے۔ نئے وینڈرز ایک موجودہ انٹرفیس کے پیچھے نیا کنکریٹ ایڈاپٹر لکھ کر شامل کیے جاتے ہیں — ڈومین ماڈیولز کو چھوا نہیں جاتا۔

// Illustrative TypeScript contract — the shape every adapter obeys.
interface RegistryAdapter {
  verifyCnic(req: CnicVerifyRequest): Promise<CnicVerifyResponse>;
  lookupCompany(req: CompanyLookupRequest): Promise<CompanyLookupResponse>;
}
interface CommsAdapter {
  sendEmail(req: EmailRequest): Promise<MessageSendResult>;
  sendSms(req: SmsRequest): Promise<MessageSendResult>;
  sendWhatsApp(req: WhatsAppRequest): Promise<MessageSendResult>;
}
interface VideoAdapter {
  createMeeting(req: MeetingCreateRequest): Promise<MeetingCreateResult>;
  getRecording(meetingId: string): Promise<RecordingResult>;
}

3. انٹیگریشن ٹیمپلیٹ

§4–§7 میں ہر انٹیگریشن کو ایک ہی ٹیمپلیٹ کے ساتھ بیان کیا گیا ہے تاکہ معاہدے موازنہ اور جائزہ لینے کے قابل ہوں۔ ٹیمپلیٹ فیلڈز:

فیلڈ	معنی
مقصد	SITP اس انٹیگریشن کو کس لیے استعمال کرتا ہے۔
سمت	اِن باؤنڈ (بیرونی → SITP)، آؤٹ باؤنڈ (SITP → بیرونی)، یا دو طرفہ۔
توثیق کا طریقہ	SITP بیرونی نظام میں کیسے توثیق کرتا ہے، اور (اِن باؤنڈ کے لیے) بیرونی نظام SITP میں کیسے توثیق کرتا ہے۔
اہم آپریشنز	وہ الگ الگ کالیں/پیغامات جو انٹیگریشن سپورٹ کرتا ہے۔
ڈیٹا معاہدہ	درخواست اور جواب فیلڈ فہرستیں (اور جہاں مددگار ہو نمونہ JSON)۔
ایرر ہینڈلنگ و SLA	سٹیٹس کوڈز ہینڈل کیے گئے، ریٹری پالیسی، سرکٹ بریکر THRESHOLD، ہدف لیٹینسی/دستیابی۔
فرضیات / منحصریات	تفاہم نامے، رجسٹریشنز، سینڈر آئی ڈی منظوریاں، ٹیمپلیٹ منظوریاں، نیٹ ورک رسائی (IP وائٹ لسٹنگ) وغیرہ۔
حیثیت	`planned` (ابھی کوئی معاہدہ نہیں) یا `contracted` (تفاہم نامہ/رسائی موجود)۔

4. حکومتی شناخت و رجسٹری انٹیگریشنز

یہ انٹیگریشنز فائل فرسٹ، متوازی تصدیق رجسٹریشن ماڈل کی بنیاد ہیں (دیکھیں _context.md §5): ایک کمپنی نمائندہ رجسٹر ہوتا ہے، ایک عارضی اکاؤنٹ حاصل کرتا ہے، فوراً فائل کرتا ہے، اور SITP NADRA، SECP، FBR، SRB، اور PSEB میں شناخت اور ادارتی حیثیت کی پس منظر میں تصدیق کرتا ہے۔ یہی ایڈاپٹرز ٹکٹ ہینڈلنگ کے دوران بھی ادھوک تصدیق کے لیے کام آتے ہیں۔

کراس کٹنگ منحصریت۔ اس سیکشن کا ہر ایڈاپٹر لائیو ہونے سے پہلے متعلقہ اتھارٹی کے ساتھ ایک تفاہم نامہ اور/یا API رجسٹریشن کا تقاضا کرتا ہے۔ یہ گورننس منحصریات ہیں، §12 میں ٹریک کیے گئے، انجینئرنگ ٹاسک نہیں۔ جب تک تفاہم نامہ دستخط نہ ہو، ایڈاپٹر کو ایک فیچر فلگ کے پیچھے ڈارک شپ کیا جاتا ہے اور لوک اپس "تصدیق زیر التواء — دستی جائزہ" لوٹاتے ہیں تاکہ رجسٹریشن بہاؤ غیر مسدود رہے۔

4.1 NADRA Verisys — CNIC و شناخت کی تصدیق

فیلڈ	قدر
مقصد	ایک نمائندہ کی شناخت کی CNIC سے تصدیق؛ نام، تاریخ پیدائش، خاندانی شجرہ، اور CNIC حیثیت (فعال/منسوخ) کی تصدیق۔ اعلیٰ اعتماد والے اعمال (بنیادی مجاز نمائندہ منتقلی، حساس ٹکٹ بندش) کے لیے اختیاری بائیو میٹرک تصدیق۔
سمت	آؤٹ باؤنڈ۔
توثیق کا طریقہ	NADRA اینڈ پوائنٹ پر IP وائٹ لسٹنگ + صارف نامہ/پاس ورڈ (یا باہمی TLS / API کلید، عملدرآمد شدہ تفاہم نامے کے مطابق)۔ کریڈینشلز خفیہ والٹ میں۔ سورس IP، SITP کا ایگریس IP ہے، NADRA کے ساتھ رجسٹرڈ۔
اہم آپریشنز	`verifyCnic(cnic)` → شناخت ریکارڈ؛ `verifyBiometric(cnic, biometricToken)` → میچ اسکور (اختیاری، فیچر فلگ سے محدود)۔
ڈیٹا معاہدہ — درخواست	`cnic` (13 ہندسے، تصدیق شدہ)، `purpose` ("registration" \| "rep-transfer" \| "sensitive-action")، اختیاری `biometricToken`۔
ڈیٹا معاہدہ — جواب	`cnic`، `nameEn`، `nameUr` (اگر دستیاب ہو)، `fatherOrHusbandName`، `dob`، `gender`، `familyTreeId`، `presentAddress`، `status` (`active` \| `cancelled` \| `not-found`)، `verificationRef` (NADRA ٹرانزیکشن آئی ڈی)، `verifiedAt`۔
ایرر ہینڈلنگ و SLA	200 → کامیابی؛ 404 → CNIC نہیں ملی (`not-found` کے طور پر لوٹائی گئی، ایرر نہیں)؛ 401/403 → کریڈینشل/IP ناکامی (آپس کو الرٹ کریں، کوئی ریٹری نہیں)؛ 408/5xx → §11.2 کے مطابق ریٹری پھر DLQ۔ ہدف p95 ≤ 8 s؛ بریکر 5 مسلسل ناکامیوں کے بعد کھلتا ہے۔
فرضیات / منحصریات	NADRA کے ساتھ Verisys API رسائی کا تفاہم نامہ۔ IP وائٹ لسٹنگ کے لیے مستحکم ایگریس IP درکار ہے۔ خود مختار ڈیٹا: یہ ایڈاپٹر صرف اون پریم یا NADRA-منظور شدہ چینل کے ذریعے جائز ہے؛ پے لوڈز Restricted ڈیٹا کلاس ہیں، `int_call` میں بھاری حذف و ترمیم کے ساتھ محفوظ کیے جاتے ہیں (صرف `verificationRef` + `status` برقرار، مکمل شناخت ریکارڈ نہیں)۔
حیثیت	`planned` — تفاہم نامہ درکار۔

4.2 SECP — کمپنی لوک اپ

فیلڈ	قدر
مقصد	اپنی انکارپوریشن/رجسٹریشن نمبر سے رجسٹرڈ کمپنی کی توثیق؛ قانونی نام، حیثیت (فعال/خاموش/استریک آف)، رجسٹرڈ دفتر، اور ڈائریکٹرز حاصل کریں۔ رجسٹریشن کے دوران تصدیق شدہ بیج اور نمائندہ اجازت کے لیے ڈائریکٹرز فہرست کو چلاتا ہے۔
سمت	آؤٹ باؤنڈ۔
توثیق کا طریقہ	API کلید + (غالباً) IP وائٹ لسٹنگ، SECP ڈیٹا رسائی تفاہم نامے کے مطابق۔
اہم آپریشنز	`lookupCompany(incorporationNo)`، `lookupCompanyByName(name)` (فزی، فائلنگ کے دوران سرچ اسسٹ کے لیے)۔
ڈیٹا معاہدہ — درخواست	`incorporationNo` (جیسے، `0012345`) یا `name`؛ `jurisdiction` (وفاقی)۔
ڈیٹا معاہدہ — جواب	`incorporationNo`، `name`، `status`، `registrationDate`، `registeredOfficeAddress`، `businessActivity`، `directors[]` (`name`، `cnic` (اگر ظاہر کیا گیا ہو)، `designation`)، `lookupRef`۔
ایرر ہینڈلنگ و SLA	§4.1 کے مطابق؛ ہدف p95 ≤ 6 s۔ صارف داخل کردہ نام اور SECP ریکارڈ کے درمیان بے میل رجسٹریشن کو آٹو ریجیکٹ کے بجائے دستی جائزے کے لیے نشان زد کرتے ہیں۔
فرضیات / منحصریات	SECP کے ساتھ تفاہم نامہ / API رجسٹریشن۔ SECP ایک پبلک نام سرچ ویب سائٹ بھی فراہم کرتا ہے جسے API تفاہم نامے کے دوران لوک اپس کے لیے فال بیک کے طور پر استعمال کیا جا سکتا ہے (دستی تصدیق)۔
حیثیت	`planned` — تفاہم نامہ درکار۔

4.3 FBR — NTN و فعال ٹیکس فائلر حیثیت

فیلڈ	قدر
مقصد	کسی کمپنی کے نیشنل ٹیکس نمبر (NTN)، فعال فائلر حیثیت، اور ٹیکس پروفائل کی تصدیق۔ تصدیق شدہ بیج میں حصہ ڈالتا ہے اور کمپنی اعتماد اسکور میں ایک اشارہ ہے۔
سمت	آؤٹ باؤنڈ۔
توثیق کا طریقہ	API کلید + IP وائٹ لسٹنگ، FBR رسائی معاہدے کے مطابق۔ FBR ایک پبلک فعال ٹیکس دہندگان کی فہرست (ATL) بھی شائع کرتا ہے جو وقتاً فوقتاً تازہ ہوتی ہے، صرف پڑھنے کے فال بیک کے طور پر استعمال ہوتی ہے۔
اہم آپریشنز	`lookupNtin(ntn)`، `filerStatus(ntnOrCnic)`۔
ڈیٹا معاہدہ — درخواست	`ntn` (7–8 ہندسے) اور/یا `cnic`۔
ڈیٹا معاہدہ — جواب	`ntin`، `name`، `status` (`active` \| `inactive`)، `filerStatus` (`active-filer` \| `non-filer`)، `taxOffice`، `businessActivity`، `asOfTaxYear`، `lookupRef`۔
ایرر ہینڈلنگ و SLA	§4.1 کے مطابق؛ ہدف p95 ≤ 6 s۔ فائلر حیثیت فی ٹیکس سالہ پوائنٹ اِن ٹائم ہے — جواب `asOfTaxYear` ریکارڈ کرتا ہے تاکہ پرانا ڈیٹا پہچانا جا سکے۔
فرضیات / منحصریات	FBR کے ساتھ تفاہم نامہ / API رسائی۔ فائلر حیثیت سالانہ بدلتی ہے؛ ATL تازہ کاری کا تاخیری فرق قابل قبول ہے۔
حیثیت	`planned` — تفاہم نامہ درکار۔

4.4 SRB — سندھ سیلز ٹیکس رجسٹریشن (STRN)

فیلڈ	قدر
مقصد	سندھ ریونیو بورڈ کی طرف سے جاری کردہ کسی کمپنی کے سیلز ٹیکس رجسٹریشن نمبر (STRN) کی توثیق — خاص طور پر سندھ میں کام کرنے والی IT/سروسز کمپنیوں کے لیے متعلقہ۔
سمت	آؤٹ باؤنڈ۔
توثیق کا طریقہ	API کلید + IP وائٹ لسٹنگ، SRB رسائی معاہدے کے مطابق۔
اہم آپریشنز	`validateStrn(strn)`۔
ڈیٹا معاہدہ — درخواست	`strn` (فارمیٹ تصدیق شدہ)۔
ڈیٹا معاہدہ — جواب	`strn`، `legalName`، `status` (`active` \| `suspended` \| `cancelled`)، `registrationDate`، `taxAuthority` (`SRB`)، `lookupRef`۔
ایرر ہینڈلنگ و SLA	§4.1 کے مطابق؛ ہدف p95 ≤ 5 s۔
فرضیات / منحصریات	SRB کے ساتھ تفاہم نامہ / API رسائی۔ SRB ایک سندھ صوباتی ادارہ ہے، اس لیے یہ اعلیٰ ترجیحی صوباتی انٹیگریشن ہے۔
حیثیت	`planned` — تفاہم نامہ درکار (صوباتی ترجیح)۔

4.5 PSEB — IT انڈسٹری ممبرشپ کی توثیق

فیلڈ	قدر
مقصد	پاکستان سافٹ ویئر ایکسپورٹ بورڈ کے ساتھ ممبرشپ کی توثیق — کمپنی ممبرشپ اور فری لینسر/انفرادی ممبرشپ دونوں۔ PSEB ممبران کو تصدیق شدہ بیج میں ایک اعتماد اشارہ ملتا ہے اور وہ IT سیکٹر ٹکٹس پر ترجیحی روٹنگ کے لیے اہل ہو سکتے ہیں۔
سمت	آؤٹ باؤنڈ۔
توثیق کا طریقہ	API کلید، PSEB ڈیٹا شیئرنگ معاہدے کے مطابق۔
اہم آپریشنز	`memberType ∈ { company, freelancer }` کے لیے `validateMembership({ memberType, membershipNo })`۔
ڈیٹا معاہدہ — درخواست	`memberType`، `membershipNo` (یا فری لینسرز کے لیے `cnic`)، `companyName`۔
ڈیٹا معاہدہ — جواب	`membershipNo`، `memberType`، `name`، `status` (`active` \| `expired` \| `not-found`)، `validUntil`، `lookupRef`۔
ایرر ہینڈلنگ و SLA	§4.1 کے مطابق؛ ہدف p95 ≤ 5 s۔ ختم شدہ ممبرشپ رجسٹریشن کو مسدود نہیں کرتی — صرف اعتماد اشارہ ہٹا دیتی ہے۔
فرضیات / منحصریات	PSEB کے ساتھ ڈیٹا شیئرنگ معاہدہ۔ PSEB ممبرشپ ڈیٹا نیاؤنل سے دنوں پیچھے رہتی ہے؛ ایک "expired" نتیجہ جو `validUntil` سے < 30 دن بعد ہو اسے "pending renewal" سمجھا جاتا ہے۔
حیثیت	`planned` — معاہدہ درکار۔

4.6 NITB e-Office — سرکاری فائل موومنٹ

فیلڈ	قدر
مقصد	ایک SITP ٹکٹ، اجلاس کی روداد، یا قرارداد سرٹیفکیٹ کو حکومت کے e-Office نظام میں بطور سرکاری فائل موومنٹ پش کریں تاکہ وصول کنندہ محکمہ اسے اپنے قانونی فائل بہاؤ کے ذریعے پروسیس کر سکے؛ حیثیت واپس کھینچیں تاکہ SITP ٹکٹ پر سرکاری فائل حالت منعکس کرے۔
سمت	دو طرفہ۔ آؤٹ باؤنڈ (فائل موومنٹ بنائیں، دستاویز منسوب کریں)؛ اِن باؤنڈ (e-Office سے حیثیت کال بیکس)۔
توثیق کا طریقہ	e-Office میں سروس اکاؤنٹ (NITB کے زیر انتظام) + API کلید؛ اِن باؤنڈ کال بیکس ایک مشترکہ HMAC راز کے ساتھ سائن کیے جاتے ہیں۔
اہم آپریشنز	`createFileMovement(ticketOrMom)`، `attachDocument(fileId, docRef)`، `getStatus(fileId)` (پول فال بیک)، اِن باؤنڈ `onStatusChange(fileId, status)`۔
ڈیٹا معاہدہ — پش درخواست	`sourceRef` (`SITP-2026-ITD-000045`)، `type` (`ticket` \| `mom` \| `resolution`)، `title`، `summary`، `originatingDept` (`S&ITD`)، `targetDept`، `priority`، `documents[]` (`fil_attachment` refs → presigned URLs جنہیں e-Office طرف فیچ کرتا ہے)، `requestedBy`۔
ڈیٹا معاہدہ — پش جواب	`fileId` (e-Office کا فائل نمبر)، `status` (`submitted`)، `acceptedAt`۔
ڈیٹا معاہدہ — حیثیت کال بیک	`fileId`، `sourceRef`، `status` (`submitted` \| `under-process` \| `approved` \| `returned` \| `rejected`)، `currentDesk`، `updatedAt`، `note`۔
ایرر ہینڈلنگ و SLA	2xx → کامیابی؛ 409 → فائل پہلے موجود (آئی ڈیمپوٹنسی کلید استعمال کرتے ہوئے آئی ڈیمپوٹنٹ کامیابی سمجھیں)؛ 5xx → §11.2 کے مطابق ریٹری پھر DLQ؛ غائب کال بیک → فال بیک کے طور پر ہر 30 منٹ میں `getStatus` پول کریں۔ پش کے لیے ہدف p95 ≤ 10 s؛ حیثیت تازگی ≤ 30 منٹ۔
فرضیات / منحصریات	NITB کے ساتھ تفاہم نامہ اور e-Office اِنسٹنس میں سروس اکاؤنٹ۔ دستاویز تبادلے کے لیے e-Office کی طرف سے presigned URLs سے فیچ کرنا ضروری ہے (یا متبادل طور پر base64 پے لوڈز وصول کرنا — ایڈاپٹر دونوں سپورٹ کرتا ہے)۔
حیثیت	`planned` — تفاہم نامہ درکار۔ اعلیٰ قدر برائے بین المحاکمتی جواز۔

5. مواصلات انٹیگریشنز

مواصلات ایڈاپٹرز اطلاع پیپ لائن کی بنیاد ہیں (دیکھیں /specs/ur/15-tech-architecture/ §12)۔ یہ بنیادی طور پر آؤٹ باؤنڈ ہیں، دو طرفہ جوابات (ای میل جواب، WhatsApp جواب) کے لیے اِن باؤنڈ راستوں کے ساتھ جو ٹکٹ تھریڈ میں شامل ہوتے ہیں۔ ہر آؤٹ باؤنڈ بھیجنے کے ساتھ ایک Idempotency-Key ہوتی ہے تاکہ دوہری قطار ملازمتیں کبھی دو بار نہ بھیجیں۔

5.1 Mailjet — ٹرانزیکشنل ای میل

فیلڈ	قدر
مقصد	ٹرانزیکشنل اطلاعات (ٹکٹ بنائی گئی/اپڈیٹ/حل، اجلاس کی روداد شائع، اسکیلیشن، ڈائجسٹس)، کثیر لسانی ٹیمپلیٹڈ ای میل، اور اِن باؤنڈ جواب پارسنگ (اطلاعاتی ای میل کا جواب اصل ٹکٹ میں شامل ہو جاتا ہے)۔
سمت	دو طرفہ (آؤٹ باؤنڈ بھیجنا؛ اِن باؤنڈ ڈلیوری/باؤنس/اسپام ویب ہوکس + جوابات کا اِن باؤنڈ پارس)۔
توثیق کا طریقہ	SMTP (پرانے بھیجنے کے راستوں کے لیے) اور REST API والٹ میں API کلید + راز کے ساتھ۔ بھیجنے والے ڈومین کی توثیق: SPF، DKIM، اور DMARC بھیجنے والے ڈومینز `maahir.io` اور `sindhitportal.maahir.io` کے لیے کنفیگر؛ Mailjet کا تصدیق شدہ بھیجنے والے ڈومین ریکارڈ موجود۔ اِن باؤنڈ ویب ہوک Mailjet کے سگنیچر ہیڈر کے ساتھ سائن، SITP کے ذریعے تصدیق شدہ۔
اہم آپریشنز	`sendEmail(...)`، `sendTemplate(...)`، اِن باؤنڈ `onDelivery`، `onBounce`، `onSpam`، `onInboundReply`۔
ڈیٹا معاہدہ — بھیجیں درخواست	`to[]`، `cc[]`، `bcc[]`، `from` (`no-reply@sindhitportal.maahir.io`)، `replyTo` (فی ٹکٹ پتہ جو اِن باؤنڈ کو SITP واپس روٹ کرتا ہے)، `templateId` (Mailjet ٹیمپلیٹ آئی ڈی)، `variables` (لوکیل، ticketId، نام، تاریخیں — گریگورین اور ہجری دونوں سرور سائیڈ پہلے سے رینڈر شدہ)، `idempotencyKey`، `tags[]` (`ticketId`، `dept`، `notificationType`)۔
ڈیٹا معاہدہ — بھیجیں جواب	`messageId` (Mailjet آئی ڈی)، `status` (`sent` \| `queued`)، `acceptedAt`۔
ڈیٹا معاہدہ — ڈلیوری ویب ہوک	`event` (`sent` \| `delivered` \| `bounce` \| `blocked` \| `spam` \| `open` \| `click`)، `messageId`، `email`، `time`، `reason`، `ticketId` (ٹیگز سے)۔
ایرر ہینڈلنگ و SLA	2xx → ٹھیک ہے؛ 422 (تصدیق) → کوئی ریٹری نہیں، لاگ کریں؛ 5xx/429 → §11.2 کے مطابق ریٹری۔ باؤنسز اور بلاکس وصول کنندہ کے `email_deliverable` فلگ کو اپڈیٹ کرتے ہیں اور اطلاع پیپ لائن کے مطابق SMS/اِن ایپ پر فال بیک ٹرگر کرتے ہیں۔ ہدف p95 ≤ 4 s بھیجنے کی تصدیق؛ ڈلیوری ایونٹ تازگی ≤ 5 منٹ۔
فرضیات / منحصریات	Mailjet اکاؤنٹ فراہم شدہ؛ بھیجنے والے ڈومینز تصدیق شدہ؛ reply-to روٹنگ کنفیگر (Mailjet ایک فی ٹکٹ اِن باؤنڈ پتہ SITP کے اِن باؤنڈ ویب ہوک پر روٹ کرتا ہے)۔ ٹرانزیکشنل ٹیمپلیٹس پہلے سے منظور شدہ (کوئی مارکیٹنگ مواد نہیں)۔
حیثیت	`contracted` (Mailjet `_context.md` §3 کے مطابق مقفل SMTP/ای میل فراہم کنندہ ہے)۔

نمونہ درخواست — ٹیمپلیٹڈ ای میل بھیجیں

POST /api/v1/integrations/mailjet/send
Authorization: Bearer <service JWT>
Idempotency-Key: 7f3c1a2e-9b44-4d21-8e6a-2c9b1f4d0a55
Content-Type: application/json

{
  "to": [{ "email": "primary.rep@acme.com.pk", "name": "Ayesha Khan" }],
  "from": { "email": "no-reply@sindhitportal.maahir.io", "name": "Sindh IT Portal" },
  "replyTo": { "email": "ticket-SITP-2026-ITD-000045@inbound.sindhitportal.maahir.io" },
  "templateId": 4821103,
  "variables": {
    "locale": "en",
    "ticketId": "SITP-2026-ITD-000045",
    "subject": "Your ticket has been assigned",
    "bodyMarkdown": "Ticket SITP-2026-ITD-000045 has been assigned to the IT Department...",
    "gregorianDate": "17 July 2026",
    "hijriDate": "2 Muharram 1448",
    "dept": "S&ITD",
    "portalUrl": "https://sindhitportal.maahir.io/tickets/SITP-2026-ITD-000045"
  },
  "tags": ["ticket:SITP-2026-ITD-000045", "type:assigned", "dept:ITD"],
  "channel": "email"
}

نمونہ جواب

HTTP/1.1 202 Accepted
Content-Type: application/json

{
  "messageId": "1948234751920384",
  "status": "queued",
  "acceptedAt": "2026-07-17T09:14:22.481Z",
  "adapter": "mailjet",
  "intCallId": "int_call_01HZX9F8K7P4N2Q3R6STV8WXY"
}

5.2 SMS گیٹ وے — Jazz / Telenor بلک SMS

فیلڈ	قدر
مقصد	OTP ڈلیوری (کمپنی نمائندوں کے لیے 2FA فال بیک)، مختصر ٹکٹ اطلاعات (بنائی گئی، تفویض، اسکیلیٹڈ، حل)، اور عملے کو اسکیلیشن الرٹس۔
سمت	دو طرفہ (آؤٹ باؤنڈ بھیجنا؛ اِن باؤنڈ ڈلیوری رپورٹس)۔
توثیق کا طریقہ	API کلید + سینڈر آئی ڈی؛ کریڈینشلز والٹ میں۔ DLT / PEPRA / پاکستان ریگولیٹری تعمیل: سینڈر آئی ڈی پہلے سے منظور شدہ؛ ٹرانزیکشنل بمقابلہ تشہیری ٹریفک الگ؛ تشہوری کلاس کے لیے آپٹ آؤٹ کا احترام (SITP صرف ٹرانزیکشنل بھیجتا ہے)۔
اہم آپریشنز	`sendSms(...)`، اِن باؤنڈ `onDeliveryReport`۔
ڈیٹا معاہدہ — بھیجیں درخواست	`to` (E.164 MSISDN، تصدیق شدہ)، `from` (منظور شدہ سینڈر آئی ڈی، جیسے، `SITP`)، `body` (کنکٹینیشن آگاہ، لوکیل درست، کوئی Urdu-in-SMS-7-bit مشکلات نہیں — Sindhi/Urdu UCS-2 کو 70 کریکٹر سیگمنٹ حد کے ساتھ ٹرگر کرتے ہیں)، `idempotencyKey`، `tags[]`۔
ڈیٹا معاہدہ — بھیجیں جواب	`messageId` (گیٹ وے آئی ڈی)، `segmentCount`، `status` (`accepted` \| `rejected`)۔
ڈیٹا معاہدہ — ڈلیوری رپورٹ	`messageId`، `msisdn`، `status` (`delivered` \| `failed` \| `pending`)، `errorCode`، `deliveredAt`۔
ایرر ہینڈلنگ و SLA	2xx → قبول شدہ؛ 4xx (غلط نمبر، سینڈر آئی ڈی مسترد) → کوئی ریٹری نہیں؛ 5xx → §11.2 کے مطابق ریٹری۔ ڈلیوری ناکامیوں سے وصول کنندہ کا `sms_deliverable` فلگ اپڈیٹ ہوتا ہے اور ای میل/اِن ایپ پر فال بیک ٹرگر ہوتا ہے۔ ہدف p95 ≤ 3 s بھیجنے کی تصدیق؛ ڈلیوری رپورٹ تازگی ≤ 10 منٹ۔ Jazz اور Telenor کے درمیان فیلیور فی پیغام کلاس کنفیگر قابل ہے۔
فرضیات / منحصریات	Jazz اور/یا Telenor کے ساتھ بلک SMS اکاؤنٹ؛ PTA رجسٹرڈ ایگریگیٹر کے ذریعے سینڈر آئی ڈی منظور شدہ؛ Sindhi کے لیے UCS-2 سپورٹ تصدیق شدہ۔
حیثیت	`contracted` (اسٹیک مقفل SMS فراہم کنندگان)۔

5.3 WhatsApp Business API — Cloud API

فیلڈ	قدر
مقصد	کمپنی نمائندوں کے ساتھ دو طرفہ چیٹ؛ ٹیمپلیٹڈ اطلاعات (ٹکٹ بنائی گئی/تفویض/حل، اجلاس کی روداد شائع)؛ اِن باؤنڈ جوابات ٹکٹ تھریڈ میں شامل ہوتے ہیں؛ آپٹ اِن/آپٹ آؤٹ مینجمنٹ۔
سمت	دو طرفہ (آؤٹ باؤنڈ ٹیمپلیٹ + سیشن پیغامات؛ اِن باؤنڈ جواب ویب ہوک)۔
توثیق کا طریقہ	WhatsApp Business Cloud API — سسٹم یوزر رسائی ٹوکن (graph API) `whatsapp_business_messaging` اجازت کے ساتھ؛ فون نمبر آئی ڈی اور WABA آئی ڈی والٹ میں۔ اِن باؤنڈ ویب ہوک `X-Hub-Signature-256` (HMAC-SHA256) تصدیق کے لیے App secret استعمال ہوتا ہے۔
اہم آپریشنز	`sendTemplate(...)`، `sendText(...)` (24 گھنٹے کسٹمر سروس ونڈو کے اندر)، `markMessageRead`، اِن باؤنڈ `onMessage` (ٹیکسٹ/میڈیا/آواز)، `onMessageStatus`، `optIn`/`optOut`۔
ڈیٹا معاہدہ — ٹیمپلیٹ بھیجیں درخواست	`to` (E.164)، `templateName` (پہلے سے منظور شدہ، جیسے، `ticket_assigned_en`)، `language` (`en` \| `ur` \| `sd`)، `components[]` (ہیڈر/باڈی پیرامیٹرز: ticketId، dept، status، portalUrl)، `idempotencyKey`۔
ڈیٹا معاہدہ — بھیجیں جواب	`messageId` (WA آئی ڈی)، `status` (`queued`)۔
ڈیٹا معاہدہ — اِن باؤنڈ ویب ہوک	`from`، `messageId`، `type` (`text` \| `image` \| `document` \| `voice`)، `text` / میڈیا ref، `timestamp`، `replyContext` (حالیہ آؤٹ باؤنڈ پیغام سے پارس شدہ ٹکٹ ref)۔
ایرر ہینڈلنگ و SLA	2xx → ٹھیک ہے؛ 4xx (ٹیمپلیٹ منظور نہیں، وصول کنندہ آپٹ آؤٹ، غیر ٹیمپلیٹ کے لیے 24h ونڈو سے باہر) → کوئی ریٹری نہیں، لاگ کریں + ڈسپیچر کو فال بیک کے لیے اطلاع دیں؛ 5xx/429 → §11.2 کے مطابق ریٹری۔ وصول کنندہ آپٹ آؤٹ فوراً معتبر کیا جاتا ہے اور ترجیح سینٹر تک پھیلایا جاتا ہے۔ ہدف p95 ≤ 5 s بھیجنے کی تصدیق؛ اِن باؤنڈ تازگی ≤ 30 s۔
فرضیات / منحصریات	WhatsApp Business Account منظور شدہ؛ ٹیمپلیٹس Meta کے ذریعے EN/UR/SD کے لیے منظور شدہ؛ ڈسپلے فون نمبر تصدیق شدہ؛ کسی بھی ٹیمپلیٹ بھیجنے سے پہلے فی وصول کنندہ واضح آپٹ اِن ریکارڈ شدہ (تعمیل)۔
حیثیت	`planned` — WABA + ٹیمپلیٹ منظوریاں درکار۔

6. ویڈیو کنفرنسنگ — Zoom / Google Meet / Microsoft Teams

فیلڈ	قدر
مقصد	فی TRI/سماعت (کمپنی + S&ITD + محکمہ) ایک ورچوئل میٹنگ بنائیں جب صرف طبعی میٹنگ ضروری نہ ہو؛ شرکاء کے لیے جوائن لنک بنائیں؛ میٹنگ کے بعد اجلاس کی روداد نکالنے کے پیپ لائن کے لیے ریکارڈنگ اور ٹرانسکرپٹ کھینچیں۔
سمت	آؤٹ باؤنڈ (میٹنگ بنائیں، ریکارڈنگ/ٹرانسکرپٹ فیچ کریں)؛ اِن باؤنڈ (اختیاری ریکارڈنگ ریڈی ویب ہوک)۔
توثیق کا طریقہ	ہر فراہم کنندہ کے ساتھ OAuth 2.0 (Zoom OAuth + Server-to-Server؛ Google Workspace ڈومین وائیڈ ڈیلیگیشن؛ Microsoft Teams ایپلیکیشن اجازتیں)۔ OAuth ٹوکنز + ریفریش ٹوکنز والٹ میں؛ شیڈولڈ ملازمت کے ذریعے ریفریش ہوتے ہیں۔
اہم آپریشنز	`createMeeting(...)`، `getJoinLink(meetingId)`، `getRecording(meetingId)`، `getTranscript(meetingId)`، اِن باؤنڈ `onRecordingReady`۔
ڈیٹا معاہدہ — بنائیں درخواست	`provider` (`zoom` \| `meet` \| `teams`)، `topic` (جیسے، `TRI — SITP-2026-ITD-000045`)، `startTime` (UTC)، `durationMinutes`، `agenda` (ٹکٹ ہسٹری سے AI کے ذریعے پہلے بھرا ہوا)، `participants[]` (ای میلز — فراہم کنندہ کے ذریعے مدعو)، `hostEmail` (S&ITD فاسیلیٹیٹر)، `record` (بولین)، `transcribe` (بولین، فیچر فلگ سے محدود)۔
ڈیٹا معاہدہ — بنائیں جواب	`provider`، `meetingId`، `joinUrl`، `hostUrl`، `password` (اگر ہو)، `calendarEventId`۔
ڈیٹا معاہدہ — ریکارڈنگ ریڈی ویب ہوک	`meetingId`، `provider`، `downloadUrl` (presigned، مختصر مدتی)، `transcriptUrl`، `durationSeconds`، `sourceRef`۔
ایرر ہینڈلنگ و SLA	2xx → ٹھیک ہے؛ 401 → ٹوکن ریفریش پھر ایک بار ریٹری؛ 4xx → کوئی ریٹری نہیں؛ 5xx → §11.2 کے مطابق ریٹری۔ فراہم کنندہ انتخاب فی میٹنگ کنفیگر قابل ہے (ایک S&ITD فاسیلیٹیٹر آج Zoom اور کل Teams منتخب کر سکتا ہے)۔ ریکارڈنگز پل (SITP فیچ کرتا ہے) پش نہیں کی جاتیں، اس لیے غائب ریکارڈنگ پول فال بیک ٹرگر کرتی ہے۔ `createMeeting` کے لیے ہدف p95 ≤ 6 s۔
فرضیات / منحصریات	Zoom، Google، اور Microsoft کے ساتھ OAuth ایپس رجسٹرڈ؛ ریکارڈنگ اور ٹرانسکرپشن فیچرز فی اکاؤنٹ فعال؛ ریکارڈنگز MinIO میں ڈاؤن لوڈ اور محفوظ (پھر ڈیٹا کلاسیفیکیشن پالیسی کے مطابق فراہم کنندہ سے حذف)۔ ٹرانسکرپٹ ٹیکسٹ اجلاس کی روداد ایکشن آئٹم ایکسٹریکٹر (AI صلاحیت #11) کو دیا جاتا ہے۔
حیثیت	`planned` — ہر فراہم کنندہ کے لیے OAuth ایپ رجسٹریشن درکار۔

7. شناخت و SSO — Keycloak کے ذریعے OIDC

فیلڈ	قدر
مقصد	OIDC SSO کے ذریعے حکومتی عملے کی فیڈریٹڈ لاگ اِن تاکہ S&ITD اور محکمہ عملہ اپنی موجودہ حکومتی شناخت (فیڈریٹڈ IdP) کے ساتھ سائن اِن کرے نہ کہ نیا SITP لوکل پاس ورڈ؛ IdP سے گروپ/کردار کلیمز کو SITP کرداروں میں میپ کریں؛ عملے کے لیے 2FA نافذ کریں۔ کمپنی نمائندے / شہری SITP لوکل Keycloak ریئلم کے ذریعے لاگ اِن (ای میل/پاس ورڈ + 2FA اختیاری)۔
سمت	دو طرفہ (SITP ↔ Keycloak؛ Keycloak ↔ حکومتی IdP)۔
توثیق کا طریقہ	PKCE کے ساتھ OIDC Authorization Code بہاؤ؛ مختصر مدتی رسائی ٹوکنز (منٹ) + ریفریش ٹوکنز (دن)، Redis پر میررڈ denylist کے ذریعے منسوخ قابل۔ کلائنٹ سیکیٹس والٹ میں۔
اہم آپریشنز	`authorize`، `token`، `userInfo`، `refresh`، `logout`، `introspect`۔
ڈیٹا معاہدہ — ٹوکن کلیمز	`sub`، `email`، `name`، `locale`، `realm` (`gov-staff` \| `company`)، `groups[]` (IdP سے، جیسے، `SITD-Staff`، `LBR-Section`)، `roles[]` (Keycloak role-claim mapper کے ذریعے گروپس سے میپ شدہ → SITP کردار: `Staff`، `POC`، `DG`، `Secretary`، `SuperAdmin`)، `deptCode`، `2fa_verified` (بولین)۔
ڈیٹا معاہدہ — RBAC میپنگ	ایک Keycloak mapper IdP گروپس کو SITP کرداروں میں ترجمہ کرتا ہے؛ SITP کا `RolesGuard`/`PermissionsGuard` کردار کلیمز استعمال کرتا ہے؛ باریاب فی اجازت اوورائیڈز SITP میں رہتے ہیں (Keycloak میں نہیں)۔
ایرر ہینڈلنگ و SLA	401 → دوبارہ توثیق کا اشارہ؛ 403 → کردار/اجازت مسترد (لاگ شدہ)؛ ٹوکن انٹروسپیکٹ ناکامیاں بند فیل (انکار)۔ Keycloak کو ایک تناؤی منحصریت سمجھا جاتا ہے — مسلسل ہیلتھ چیک شدہ۔
فرضیات / منحصریات	Keycloak سیلف ہوسٹڈ (اسٹیک مقفل)؛ حکومتی IdP فیڈریشن کے لیے حکومتی شناخت اتھارٹی کے ساتھ ہم آہنگی ضروری (جیسے، NADRA FBR طرز کا عملے کا IdP یا محکماتی AD)۔ جب تک فیڈریشن موجود نہ ہو، عملہ لازمی 2FA کے ساتھ Keycloak لوکل اکاؤنٹس استعمال کرتا ہے۔
حیثیت	`contracted` (Keycloak اسٹیک مقفل)؛ فیڈریشن راستہ IdP معاہدے کی منتظری میں `planned`۔

8. پبلک API (کنزیومرز کے لیے)

SITP مجاز پارٹنر کنزیومرز — دیگر حکومتی پورٹلز، انٹیگریشن پارٹنرز، اور بڑی کمپنی ٹیننٹس جو پروگرامی طور پر ٹکٹس فائل اور ٹریک کرنا چاہتے ہیں — کے لیے /api/v1 پر ایک ورژن شدہ REST API بے نقاب کرتا ہے۔ پبلک API OpenAPI 3.1 کے طور پر دستاویز شدہ ہے، /api/v1/openapi.json پر پیش کیا جاتا ہے اور /docs/api پر رینڈر ہوتا ہے۔

8.1 روایات

موضوع	معیار
ورژننگ	URL سیگمنٹ ورژننگ (`/api/v1`، `/api/v2`)۔ توڑنے والی تبدیلیوں کے لیے نیا میجر ورژن درکار؛ پرانا ورژن ≥ 12 ماہ تک متوازی سپورٹ شدہ۔
توثیق	مشین ٹو مشین پارٹنرز کے لیے OAuth 2.0 کلائنٹ کریڈینشلز بہاؤ (client_id + client_secret → بیئرر رسائی ٹوکن، ≤ 1 گھنٹہ TTL)؛ صرف پڑھنے کے پبلک وسائل کے لیے اختیاری پارٹنر API کلیدز۔ ٹوکنز اسکوپ محدود (`tickets:write`، `tickets:read`، `kb:read`، `stats:read`)۔
ریٹ لimitz	فی اسٹیٹ (`int_ratelimit` میں کنفیگر قابل): پڑھنے کے لیے فی پارٹنر ڈیفالٹ 600 req/min؛ ٹکٹ بنانے کے لیے 60 req/min۔ 429 `Retry-After` کے ساتھ لوٹایا گیا۔ برساتی پارٹنرز تھروٹل ہوتے ہیں، بغیر اطلاع کبھی بین نہیں کیے جاتے۔
پیجینیشن	کرسر بیسڈ (`?cursor=...&limit=50`، زیادہ سے زیادہ `limit=100`) لسٹ اینڈ پوائنٹس کے لیے؛ کل تعدادیں جہاں سستے حساب سے جا سکیں، ایک `meta` بلاک میں لوٹائی جاتی ہیں۔
فلٹرنگ	کئوری سٹرنگ فلٹرز (`?status=...&dept=...&since=...`)؛ فلٹرز سرور سائیڈ وائٹ لسٹ تصدیق شدہ۔
ایررز	RFC 7807 `application/problem+json` `type`، `title`، `status`، `detail`، `instance` کے ساتھ، ساتھ ہی SITP مخصوص `code` (جیسے، `SITP-VALIDATION-001`)۔
آئی ڈیمپوٹنسی	تمام POST/PUT `Idempotency-Key` قبول کرتے ہیں؛ 24 گھنٹے ونڈو کے اندر ایک ہی کلید اصل جواب لوٹاتی ہے۔
لوکیلائزیشن	`Accept-Language: en

8.2 اہم وسائل

وسیلہ	طریقے	اسکوپ	نوٹس
`/partners/tokens`	POST	—	کلائنٹ کریڈینشلز کا تبادلہ بیئرر ٹوکن کے لیے۔
`/tickets`	GET, POST	`tickets:read`, `tickets:write`	مجاز پارٹنرز کسی کمپنی کی طرف سے ٹکٹس بناتے/ٹریک کرتے ہیں (اس کمپنی کی `companyId` کے ساتھ)۔
`/tickets/{ticketId}`	GET	`tickets:read`	واحد ٹکٹ حیثیت، SLA، ہسٹری کے ساتھ (کردار فلٹر شدہ)۔
`/tickets/{ticketId}/messages`	GET, POST	`tickets:write`	ایک پبلک پیغام شامل کریں؛ پیغامات لسٹ کریں۔
`/kb/articles`	GET	`kb:read`	پبلک KB مضامین (پبلک سبسیٹ کے لیے کوئی توثیق درکار نہیں)۔
`/stats/public`	GET	`stats:read` یا پبلک	پبلک شفافیت ڈیش بورڈ ایگریگیٹس (گمنام شدہ)۔
`/departments`	GET	پبلک	محکمہ ڈائرکٹری + سروس کیٹلاگ۔
`/service-catalog`	GET	پبلک	پیش کردہ سروسز اقسام، SLA، اور مطلوبہ فیلڈز کے ساتھ۔
`/webhooks/subscriptions`	GET, POST, DELETE	`webhooks:manage`	آؤٹ باؤنڈ ویب ہوک سبسکرپشنز کا انتظام (دیکھیں §9)۔

8.3 مثال — ایک ٹکٹ بنائیں (پارٹنر)

درخواست

POST /api/v1/tickets
Authorization: Bearer <partner bearer token>
Idempotency-Key: 9a2c4e6b-1f3d-4a2c-9e8b-7d6c5b4a3f2e
Content-Type: application/json
Accept-Language: en

{
  "companyId": "cmp_01HZX7K4P9N2Q3R6STV8WXYPJ",
  "title": "Pending sales tax refund for Q4 2025",
  "description": "Our company filed the Q4 2025 SRB refund on 15 Jan 2026; no acknowledgment received.",
  "category": "SRB-REFUND",
  "targetDept": "SRB",
  "priority": "normal",
  "language": "en",
  "attachments": [
    { "filename": "SRB-Q4-2025-filing.pdf", "mimeType": "application/pdf", "size": 482310,
      "uploadId": "fil_upl_01HZX9F8K7P4N2Q3R6STV8WXY" }
  ],
  "requestedBy": { "repId": "rep_01HZX7K4P9N2Q3R6STV8WXYPJ" }
}

جواب

HTTP/1.1 201 Created
Content-Type: application/json
Location: /api/v1/tickets/SITP-2026-SRB-000128

{
  "ticketId": "SITP-2026-SRB-000128",
  "status": "new",
  "state": "triage-pending",
  "category": "SRB-REFUND",
  "targetDept": "SRB",
  "priority": "normal",
  "sla": { "responseBy": "2026-07-19T09:00:00Z", "resolveBy": "2026-07-27T09:00:00Z" },
  "createdAt": "2026-07-17T09:18:42.117Z",
  "portalUrl": "https://sindhitportal.maahir.io/tickets/SITP-2026-SRB-000128",
  "attachments": [
    { "filename": "SRB-Q4-2025-filing.pdf", "attachmentId": "fil_att_01HZX9F8K7P4N2Q3R6STV8WXZ" }
  ]
}

8.4 ایررز (RFC 7807)

HTTP/1.1 422 Unprocessable Entity
Content-Type: application/problem+json

{
  "type": "https://sindhitportal.maahir.io/docs/errors/validation",
  "title": "Validation failed",
  "status": 422,
  "detail": "companyId does not match the partner's authorized scope.",
  "instance": "/api/v1/tickets",
  "code": "SITP-VALIDATION-042",
  "errors": [{ "field": "companyId", "code": "SCOPE_MISMATCH" }]
}

9. ویب ہوکس

ویب ہوکس پارٹنرز کو SITP ایونٹس پر رئیل ٹائم میں رد عمل ظاہر کرنے (آؤٹ باؤنڈ) اور بیرونی نظاموں کو SITP میں ایونٹس پش کرنے (اِن باؤنڈ) کی اجازت دیتے ہیں۔

9.1 آؤٹ باؤنڈ ویب ہوکس

ایونٹ	ٹرگر	عام کنزیومر
`ticket.created`	کسی پارٹنر کی کمپنی کی طرف سے/کے لیے نیا ٹکٹ فائل شدہ	پارٹنر CRM
`ticket.assigned`	ٹکٹ کسی محکمے کو تفویض	پارٹنر
`ticket.status_changed`	کوئی بھی حیثیت تبدیلی (triaged، in-progress، resolved، closed، reopened، appealed)	پارٹنر
`ticket.escalated`	اسکیلیشن لیڈر اسٹیپ فائر شدہ	پارٹنر + نگرانی ڈیش بورڈ
`mom.published`	کسی ٹکٹ پر اجلاس کی روداد شائع	پارٹنر
`ticket.resolved`	حل ثبوت گیٹ مطمئن	پارٹنر
`ticket.closed`	آٹو کلوز یا کمپنی قبول	پارٹنر

ڈلیوری معاہدہ:

ٹرانسپورٹ: پارٹنر کے رجسٹرڈ اینڈ پوائنٹ پر HTTPS POST، JSON باڈی، Content-Type: application/json۔
سائننگ: ہر پے لوڈ سبسکرپشن کے مشترکہ راز کے ساتھ HMAC-SHA256 سائن شدہ ہے؛ سگنیچر X-SITP-Signature ہیڈر میں t=<unix-ts>,v1=<hex-signature> کے طور پر <ts>.<body> سٹرنگ پر بھیجا جاتا ہے۔ پارٹنرز HMAC دوبارہ حساب لے کر تصدیق کرتے ہیں۔
ری پلے تحفظ: ہیڈر میں ٹائم اسٹیمپ چیک کیا جاتا ہے؛ 5 منٹ پرانے درخواستیں پارٹنر کے ذریعے مسترد ہوتی ہیں۔ ویب ہوک ایک eventId اور deliveryId بھی رکھتا ہے؛ SITP دونوں کو int_webhook_delivery میں ریکارڈ کرتا ہے۔
ریٹری: غیر 2xx جوابات exponential backoff کے ساتھ ریٹرائی ہوتے ہیں (10s، 30s، 2m، 10m، 1h، 6h، 24h — 7 کوششیں)؛ ختم ہونے کے بعد ڈلیوری failed فلگ ہو جاتی ہے اور دستی ری پلے کے لیے پارٹنر ڈیش بورڈ میں دکھائی دیتی ہے۔
ترتیب: ایک ہی ticketId کے ایونٹس فی اینڈ پوائنٹ قطار کے ذریعے ترتیب میں ڈلیور ہوتے ہیں؛ کراس ٹکٹ ترتیب کی ضمانت نہیں۔
آئی ڈیمپوٹنسی: پارٹنرز کو eventId پر ڈیڈوکیٹ کرنا ہوگا؛ SITP دوبارہ ڈلیور کر سکتا ہے۔

نمونہ آؤٹ باؤنڈ ویب ہوک پے لوڈ (سائن شدہ)

POST https://partner.example.org/sitp/webhook
Content-Type: application/json
X-SITP-Event: ticket.status_changed
X-SITP-Signature: t=1752752322,v1=5b1c3729d4f8a2e6b0c1d9e7f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2
X-SITP-Delivery: dlv_01HZX9F8K7P4N2Q3R6STV8WXZ

{
  "eventId": "evt_01HZX9F8K7P4N2Q3R6STV8WXAB",
  "eventType": "ticket.status_changed",
  "occurredAt": "2026-07-17T09:38:42.000Z",
  "version": "1",
  "data": {
    "ticketId": "SITP-2026-SRB-000128",
    "companyId": "cmp_01HZX7K4P9N2Q3R6STV8WXYPJ",
    "previousStatus": "new",
    "status": "assigned",
    "assignedTo": { "dept": "SRB", "section": "Refunds" },
    "sla": { "responseBy": "2026-07-19T09:00:00Z" },
    "portalUrl": "https://sindhitportal.maahir.io/tickets/SITP-2026-SRB-000128"
  },
  "delivery": { "deliveryId": "dlv_01HZX9F8K7P4N2Q3R6STV8WXZ", "attempt": 1 }
}

سگنیچر HMAC_SHA256(secret, "1752752322." + rawBody) کے طور پر حساب ہوتا ہے اور v1 کے طور پر hex-encoded بھیجا جاتا ہے۔ پارٹنرز ہیڈر سے t پڑھتے ہیں، اگر abs(now - t) > 300 ہو تو مسترد کرتے ہیں، پھر t + "." + rawRequestBody پر HMAC دوبارہ حساب لے کر موازنہ کرتے ہیں۔ data بلاک ورژن شدہ ہے (version: "1") تاکہ شکل موجودہ پارسرز کو توڑے بغیر ارتقا پا سکے؛ ایک میجر تبدیلی version: "2" کے طور پر پارٹنرز کے منتقل ہونے تک متوازی ڈلیوری کے ساتھ آتی ہے۔

9.2 اِن باؤنڈ ویب ہوکس

اِن باؤنڈ ویب ہوکس وہ طریقہ ہے جس کے ذریعے بیرونی نظام SITP میں ایونٹس پش کرتے ہیں۔ ویب ہوک وصول کنندہ ان سب کے لیے واحد سامنے کا دروازہ ہے: یہ دستخط کی تصدیق کرتا ہے، ری پلےز مسترد کرتا ہے، ایک اندرونی ایونٹ میں نارمالائز کرتا ہے، اور ایک ورکر کے ذریعے صحیح ڈومین ماڈیول میں بھیجنے کے لیے BullMQ قطار میں شامل کرتا ہے۔

سورس	ایونٹ	ڈومین اثر
Mailjet	`delivered`، `bounce`، `blocked`، `spam`	وصول کنندہ ڈلیوریبلٹی فلگز اپڈیٹ کریں۔
Mailjet (اِن باؤنڈ پارس)	جواب ای میل	reply-to پتے سے پارس شدہ ٹکٹ میں شامل کریں؛ ناظرین کو اطلاع دیں۔
WhatsApp Cloud API	اِن باؤنڈ پیغام / حیثیت	ٹکٹ میں جواب شامل کریں؛ ڈلیوری حیثیت اپڈیٹ کریں۔
SMS گیٹ وے	ڈلیوری رپورٹ	`sms_deliverable` فلگ اپڈیٹ کریں۔
NITB e-Office	`onStatusChange`	ٹکٹ کی e-Office فائل حیثیت اپڈیٹ کریں؛ "under official process" دکھائیں۔
ویڈیو فراہم کنندہ	ریکارڈنگ ریڈی	ریکارڈنگ فیچ → اجلاس کی روداد پیپ لائن ٹرگر کریں۔
پارٹنر (پش بیک)	اقراریہ، مخصوص حیثیت	پارٹنر انٹیگریشن ریکارڈ اپڈیٹ کریں۔

ہر اِن باؤنڈ پے لوڈ کو (حساس فیلڈز حذف شدہ) int_call میں سمت inbound، سورس، دستخط تصدیق نتیجہ، اور ڈسپیچ نتیجے کے ساتھ ریکارڈ کیا جاتا ہے۔

10. ڈیٹا میپنگ و ماسٹر ڈیٹا

ہر بیرونی نظام اپنے فیلڈ نام اور کوڈ سیٹ بولتا ہے؛ SITP ایک کینونیکل ماڈل رکھتا ہے اور ایڈاپٹر سرحد پر ترجمہ کرتا ہے۔

10.1 ماسٹر ڈیٹا میپنگز

میپنگ	سورس	SITP کینونیکل	نوٹس
محکمہ کوڈ	بیرونی (e-Office، IdP گروپ نام)	`dept_code` (جیسے، `ITD`، `LBR`، `SRB`)	`int_dept_map` میں برقرار؛ ایک سمت = لوک اپ، دوسری = اِنورس لوک اپ۔
سروس/زمرہ کوڈ	سروس کیٹلاگ (اندرونی) ↔ بیرونی محکمہ اقسام	`category_code` (جیسے، `SRB-REFUND`)	آٹو روٹنگ چلاتا ہے۔
حیثیت کوڈز	ہر ایڈاپٹر کی حیثیت الفاظ	SITP ٹکٹ لائف سائیکل enum	e-Office حیثیات (`submitted`، `under-process`، `approved`، `returned`، `rejected`) ٹکٹ حالت توسیعات میں میپ ہوتی ہیں، متبادل نہیں۔
لوکیل	ISO 639-1 (`en`، `ur`، `sd`)	وہی	ٹیمپلیٹس اور AI ترجمے میں استعمال۔
کیلنڈر	گریگورین (اسٹوریج) ↔ ہجری (ڈسپلے)	دونوں	پیشکش پر حساب؛ کبھی دو بار محفوظ نہیں۔

10.2 آئی ڈیمپوٹنسی و میٹلی توافق

آئی ڈیمپوٹنسی کلیدز آؤٹ باؤنڈ کالز کے لیے SITP جنریٹ کردہ UUIDs اور اِن باؤنڈ ویب ہوکس کے لیے int_call قطار IDs ہیں؛ ایک ہی کلید ہمیشہ 24 گھنٹے ونڈو کے اندر اصل نتیجہ لوٹاتی ہے۔
توافق (Reconciliation): ایک شیڈولڈ ملازمت ہر انٹیگریشن کی حالیہ آؤٹ باؤنڈ کالوں کا متوقع نتائج سے موازنہ کرتا ہے (جیسے، "ہر رجسٹرڈ کمپنی کے پاس فائلنگ کے 24 گھنٹے اندر NADRA + SECP + FBR تصدیق ریکارڈ ہونا چاہیے")۔ خلا آپس ڈیش بورڈ میں دستی توافق کے لیے سامنے آتے ہیں۔
ماسٹر ڈیٹا سنک: محکمہ/زمرہ میپنگز ورژن شدہ ہیں؛ تبدیلیاں int_map_change میں آڈٹ ہوتی ہیں تاکہ تاریخی ٹکٹس اپنا روٹنگ کانٹیکسٹ میپنگ کے نام تبدیل ہونے کے بعد بھی برقرار رکھیں۔

11. انٹیگریشنز کے لیے غیر فنکشنل تقاضے

یہ NFRs ہر ایڈاپٹر پر لاگو ہوتے ہیں اور انٹیگریشن لیئر کا آپریشنل معاہدہ ہیں۔ پورے نظام کے مستند NFRs 03-non-functional-requirements/en.md میں ہیں؛ یہاں کی اشیاء انٹیگریشن مخصوص باریاں ہیں۔

آئی ڈی	موضوع	ہدف
`NFR-INT-001`	ٹائم آؤٹ (ڈیفالٹ)	فی کال 10 s کنیکٹ + جواب، فی ایڈاپٹر کنفیگر قابل (جیسے، NADRA 8 s، Mailjet 4 s، SMS 3 s، e-Office پش 10 s)۔
`NFR-INT-002`	ریٹریز	exponential backoff + jitter کے ساتھ زیادہ سے زیادہ 5 کوششیں: 1s، 4s، 16s، 60s، 240s (کیپڈ)۔ 4xx (non-401/429) ریٹرائی نہیں ہوتے۔
`NFR-INT-003`	سرکٹ بریکر THRESHOLDS	5 مسلسل ناکامیوں یا 30 s میں > 50% ناکامی ریٹ کے بعد کھلے؛ 60 s بعد ہاف اوپن؛ 5 کامیاب ہاف اوپن کالز کے بعد بند۔ فی ایڈاپٹر۔
`NFR-INT-004`	آئی ڈیمپوٹنسی ونڈو	24 گھنٹے؛ SITP جنریٹ کردہ UUID یا وینڈر آئی ڈیمپوٹنسی ٹوکن سے کلید شدہ؛ جوابات کیشڈ اور کلید میچ پر ری پلے۔
`NFR-INT-005`	DLQ	فی ایڈاپٹر ڈیڈ لیٹر کیو؛ کسی بھی DLQ انٹری پر الرٹ فائر؛ آپس ڈیش بورڈ + ری پلے UI؛ زیادہ سے زیادہ برقراری 30 دن پھر ایکسپورٹ۔
`NFR-INT-006`	دستیابی	انٹیگریشن لیئر ≥ 99.9% SITP کے اندر سے ناپی گئی؛ فی ایڈاپٹر دستیابی وینڈر پر منحصر ہے اور الگ سے اسٹیٹس پیج میں ٹریک ہوتی ہے۔
`NFR-INT-007`	خفیہ چیزیں روٹیشن	فراہم کنندہ کریڈینشلز ہر 90 دن (یا وینڈر پالیسی کے مطابق، جو بھی چھوٹا ہو) روٹیٹ؛ روٹیشن ایک دستاویزی رن بک ہے؛ OAuth ٹوکنز خودکار ریفریش؛ روٹیشن ایونٹس آڈٹ شدہ۔
`NFR-INT-008`	فی انٹیگریشن مشاہدہ	ہر کال ایک OTel اسپین `adapter`، `operation`، `outcome` ٹیگز کے ساتھ خارج کرتی ہے؛ Grafana میں فی ایڈاپٹر p50/p95/p99 لیٹینسی، ایرر ریٹ، اور DLQ گہرائی ڈیش بورڈز؛ لیٹینسی اور ایرر اناملیز پر الرٹس۔
`NFR-INT-009`	آڈٹ برقراری	`int_call` قطاریں ڈیٹا کلاسیفیکیشن پالیسی کے مطابق برقرار (ڈیفالٹ 2 سال ہاٹ، اس کے بعد آرکائیو شدہ)؛ حساس فیلڈز لکھنے کے وقت حذف شدہ۔
`NFR-INT-010`	ڈیٹا رہائش	خود مختار ڈیٹا ایڈاپٹرز (NADRA، CNIC رکھنے والے) اون پریم یا وینڈر منظور شدہ چینلز تک محدود؛ پے لوڈز Restricted ڈیٹا کلاس ہیں۔

12. انٹیگریشن روڈ میپ

انٹیگریشنز منحصریت (تفاہم نامہ/رسائی) اور قدر (کیا فائل فرسٹ رجسٹریشن بہاؤ اور ٹکٹ لائف سائیکل کو غیر مسدود کرتا ہے) کے مطابق ترتیب دیے جاتے ہیں۔ فیز میپنگ /specs/ur/14-roadmap-release/ کے مطابق ہے۔

12.1 فیز 1 — MVP کور (لانچ پر ضروری)

انٹیگریشن	فیز 1 کیوں	منحصریت
Mailjet (ای میل)	بنیادی اطلاع چینل؛ ٹرانزیکشنل بہاؤ اس پر منحصر۔	Mailjet اکاؤنٹ (✅ اسٹیک مقفل)؛ بھیجنے والے ڈومین کی توثیق۔
SMS گیٹ وے (Jazz/Telenor)	OTP + تناؤی اطلاعات۔	بلک SMS اکاؤنٹ؛ سینڈر آئی ڈی منظوری۔
Keycloak OIDC (لوکل + عملے 2FA)	توثیق کی ریڑھ کی ہڈی۔	سیلف ہوسٹڈ (✅ اسٹیک مقفل)۔
پبلک REST API v1 (ٹکٹس + KB + اسٹیٹس)	پارٹنر آن بورڈنگ اور شفافیت۔	کوئی بیرونی نہیں۔

12.2 فیز 2 — رجسٹری تصدیق لہر (فائل فرسٹ ان پر منحصر)

انٹیگریشن	فیز 2 کیوں	منحصریت
NADRA Verisys	نمائندہ شناخت تصدیق — تصدیق شدہ بیج کی بنیاد۔	NADRA کے ساتھ تفاہم نامہ؛ IP وائٹ لسٹنگ۔
SECP	کمپنی لوک اپ — تصدیق شدہ بیج کی بنیاد۔	SECP کے ساتھ تفاہم نامہ / API رسائی۔
FBR (NTN + فائلر)	ٹیکس پروفائل — تصدیق شدہ بیج کی بنیاد۔	FBR کے ساتھ تفاہم نامہ / API رسائی۔
SRB (STRN)	سندھ IT کمپنیوں کے لیے صوباتی ترجیح۔	SRB کے ساتھ تفاہم نامہ / API رسائی۔
PSEB	ممبرشپ اعتماد اشارہ۔	PSEB کے ساتھ ڈیٹا شیئرنگ معاہدہ۔
WhatsApp Business API	دو طرفہ چیٹ + ٹیمپلیٹڈ اطلاعات۔	WABA منظوری + ٹیمپلیٹ منظوریاں۔

12.3 فیز 3 — فائل موومنٹ و بھرپور تعاون

انٹیگریشن	فیز 3 کیوں	منحصریت
NITB e-Office	سرکاری فائل موومنٹ — بین المحاکمتی جواز۔	NITB کے ساتھ تفاہم نامہ؛ e-Office سروس اکاؤنٹ۔
ویڈیو فراہم کنندگان (Zoom/Meet/Teams)	ہائبرڈ TRI/سماعت ورچوئل میٹنگز۔	فی فراہم کنندہ OAuth ایپ رجسٹریشن۔
آؤٹ باؤنڈ ویب ہوکس	پارٹنر ایونٹ ڈلیوری۔	کوئی بیرونی نہیں (کنزیومر چلائو)۔
حکومتی IdP تک OIDC فیڈریشن	عملے کی سنگل سائن اون۔	حکومتی IdP معاہدہ۔

12.4 فیز 4+ — ملتوی / تلاشی

اِن باؤنڈ IVR / ٹول فری آواز انٹیگریشن۔
موجودہ سی ایم شکایت سیل (istd.sindh.gov.pk/complains) کے ساتھ براہ راست انٹیگریشن — صرف اگر ڈیٹا شیئرنگ پر اتفاق ہو؛ V1 کے دائرہ کار سے باہر۔
اضافی ویڈیو فراہم کنندگان یا ہائبرڈ سماعتوں کے لیے PSTN-dialout۔
React Native ایپ کی آمد پر FCM/APNS کے ذریعے پبلک موبائل ایپ پش۔

12.5 منحصریت خلاصہ

منحصریت	قسم	مسدود
NADRA Verisys تفاہم نامہ	گورننس	نمائندہ شناخت تصدیق۔
SECP API رسائی	گورننس	کمپنی تصدیق۔
FBR API رسائی	گورننس	ٹیکس تصدیق۔
SRB API رسائی	گورننس	STRN تصدیق (صوباتی)۔
PSEB ڈیٹا شیئرنگ	گورننس	ممبرشپ توثیق۔
NITB e-Office تفاہم نامہ + سروس اکاؤنٹ	گورننس + تکنیکی	سرکاری فائل موومنٹ۔
Mailjet بھیجنے والے ڈومین توثیق	تکنیکی	آؤٹ باؤنڈ ای میل ساکھ۔
SMS سینڈر آئی ڈی (PTA) منظوری	ریگولیٹری	SMS ڈلیوری۔
WhatsApp WABA + ٹیمپلیٹس	وینڈر	WhatsApp اطلاعات + دو طرفہ چیٹ۔
حکومتی IdP فیڈریشن	گورننس	عملے SSO۔
Zoom/Google/Microsoft OAuth ایپس	وینڈر	TRI/سماعت ویڈیو۔

جب تک ہر منحصریت بند نہ ہو، متعلقہ ایڈاپٹر ایک فیچر فلگ کے پیچھے ڈارک شپ ہوتا ہے اور نظام نرمی سے گراڈ ہوتا ہے (جیسے، تصدیق "pending manual review" لوٹاتی ہے؛ اطلاعات ایک کام کرنے والے چینل پر فال بیک ہوتی ہیں)۔

13. کھلے سوالات / TBD

#	شے	حیثیت
1	فی حکومتی رجسٹری درست API معاہدہ — اکثر اتھارٹیز صرف غیر رسمی دستاویزات شائع کرتی ہیں؛ رسمی اسپیسیفیکیشنز فی تفاہم نامہ طے پاتی ہیں۔	فی تفاہم نامہ TBD۔
2	کیا NADRA Verisys API کے ذریعے بائیو میٹرک ٹوکنز سپورٹ کرتا ہے یا صرف مخصوص آلات کے ذریعے۔	NADRA کے ساتھ TBD۔
3	بنیادی SMS ایگریگیٹر (Jazz بمقابلہ Telenor) کا انتخاب اور کیا دونوں فیلیور کے لیے کنٹریکٹ ہیں۔	TBD (پروکیورمنٹ)۔
4	کیا e-Office انٹیگریشن presigned URL کے ذریعے دستاویزات فیچ کرتا ہے یا base64 پش کی ضرورت ہے (ایڈاپٹر دونوں سپورٹ کرتا ہے — NITB صلاحیت کے مطابق حتمی کریں)۔	NITB کے ساتھ TBD۔
5	عملے کی فیڈریشن کے لیے حکومتی IdP (موجودہ محکماتی AD، یا نیا سندھ وائیڈ IdP)۔	TBD۔
6	فی پارٹنر ٹیئر (ڈیفالٹ بمقابلہ پریمیم) پبلک API ریٹ لimit چھتیں۔	TBD (تجارتی)۔
7	فی ڈیٹا کلاس `int_call` آڈٹ قطاروں کی برقراری کی مدت۔	ڈیٹا کلاسیفیکیشن پالیسی کے ساتھ TBD (دیکھیں `/specs/ur/11-security-compliance/`)۔

دستاویز کا اختتام۔