انٽيگريشنز اسپيسيفيڪيشن

هر انٽيگريشن جو معاهدو ۽ پليٽ فارم انٽيگريشن ليئر (API، ويب هوڪس، SSO) جو سندھ آءِ ٽي پورٽل — سهولت ڊيسڪ (SITP) کي حڪومتي رجسٽرين، مواصلات فراهم ڪندڙن، ويڊيو پليٽ فارمز، ۽ پارٽنر کنزيومرز سان ڳنڍيندو آهي.

فيلڊ	قدر
دستاويز آءِ ڊي	08
حيثيت	ڊرافٽ
مالڪ	S&ITD / MAAHIR
ٻوليون	EN (master) · UR · SD
لاڳاپيل دستاويزون	`/specs/sd/15-tech-architecture/`، `/specs/sd/12-api-contract/`، `/specs/sd/11-security-compliance/`، `03-non-functional-requirements/en.md`، `/specs/sd/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/sd/15-tech-architecture/ §13 ۾ تفصيلي آهن. هي دستاويز ٽيڪ آرڪيٽيڪچر جي §13 کي هر انٽيگريشن جي معاهدي ۾ پکيڙي ٿي. جتي هي دستاويز ۽ ٽيڪ آرڪيٽيڪچر ۾ اختلاف هجي، ٽيڪ آرڪيٽيڪچر پليٽ فارم لاءِ سرچ سماءِ ۽ هي دستاويز انفرادي انٽيگريشن معاهدن لاءِ سرچ سماءِ آهي.

2. انٽيگريشن فن تعمير

هر بيروني نظام — حڪومتي رجسٽري، مواصلات فراهم ڪندڙ، ويڊيو پليٽ فارم، پارٽنر کنزيومر — تائين رسائي صرف NestJS Integrations ماڊيول جي اندر هڪ ايڊاپٽر ذريعي ٿيندي آهي. Integrations کان ٻاهر ڪو به ماڊيول وينڊر SDK امپورٽ نٿو ڪري، سڌوسنڌون وينڊر HTTP اينڊ پوائنٽ ڪال نٿو ڪري، يا وينڊر ڪريڊينشل نٿو پڙهي. هي نظام جي اینٽي ڪرپشن (anti-corruption) سرحد آهي: اها SITP جي ڊومين ٻولي ۽ ڊيٽا ماڊل کي هر بيروني نظام جي عجيب و غريب خصوصيتن، اسڪيما تبديلين، ۽ اسٽيج کان الڳ ٿلگ رکي ٿي.

2.1 تعميراتي غير متغيرات

#	غير متغير	نفاذ
1	ايڊاپٽر پیٽرن	هر بيروني نظام جو بلڪل هڪ ايڊاپٽر ماڊيول آهي جيڪو هڪ مستحڪم اندروني انٽرفيس کي نافذ ڪري ٿو. سڀ ڪال سائيٽس انٽرفيس لاءِ پروگرام ڪن ٿا، ڪڏهن SDK لاءِ نہ.
2	اینٽي ڪرپشن ليئر	ايڊاپٽرز بيروني پے لوڊز کي SITP ڊومين آبجيڪٽس ۾ ۽ واپس ترجمو ڪن ٿا. بيروني فيلڊ نالو ڪڏهن ايڊاپٽر کان پري ليڪ نٿو ٿئي.
3	خفيه شيون والٽ ۾	ڪريڊينشلز، API ڪليڊز، سائننگ سيڪريٽس، ۽ OAuth ڪلائنٽ سيڪريٽس خفيه والٽ ۾ رهن ٿا (ڏسو `/specs/sd/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/sd/15-tech-architecture/ §12). اهي بنيادي طور تي آئوٽ بائونڊ آهن، ٻه طرفن جوابن (اي ميل جواب، WhatsApp جواب) لاءِ اِن بائونڊ رستن سان جيڪي ٽِڪيٽ ٿريڊ ۾ شامل ٿيندا آهن. هر آئوٽ بائونڈ موڪلڻ سان هڪ Idempotency-Key هوندي آهي تہ جيئن ٻٽيون قطار نوڪريون ڪڏهن ٻه ڀيرا نہ موڪليون.

5.1 Mailjet — ٽرانزيڪشنل اي ميل

فيلڊ	قدر
مقصد	ٽرانزيڪشنل اطلاعون (ٽِڪيٽ ٺاهي وئي/اپڊيٽ/حل، اجلاس جي روداد شائع، اِسڪيليشن، ڊائجسٽس)، ڪثير لساني ٽيمپليٽڊ اي ميل، ۽ اِن بائونڊ جواب پارسنگ (اطلاعي اي ميل جو جواب اصل ٽِڪيٽ ۾ شامل ٿي ويندو آهي).
سمت	ٻه طرفو (آئوٽ بائونڊ موڪلڻ؛ اِن بائونڊ ڊليوري/بائونس/اسپام ويب هوڪس + جوابن جو اِن بائونڊ پارس).
توثيق جو طريقو	SMTP (پراڻن موڪلڻ جي رستن لاءِ) ۽ REST API والٽ ۾ API ڪليچ + راز سان. موڪلڻ واري ڊومين جي توثيق: موڪلڻ واري ڊومينز `maahir.io` ۽ `sindhitportal.maahir.io` لاءِ SPF، DKIM، ۽ DMARC کنفيگر؛ 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`).
ريٽ لمٽس	في اسٽيٽ (`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/sd/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 ريٽ لمٽ چھتنون.	TBD (تجارتي).
7	في ڊيٽا ڪلاس `int_call` آڊٽ قطارن جي برقراري جي مدت.	ڊيٽا ڪلاسيفڪيشن پاليسي سان TBD (ڏسو `/specs/sd/11-security-compliance/`).

دستاويز جو اختتام.