ویب ہُک ڈیبگنگ اور مانیٹرنگ: مکمل ٹربل شوٹنگ گائیڈ

2025 کے Merge.dev کے سروے سے معلوم ہوا ہے کہ API کے انضمام کی ناکامیوں کا %62 % web ہُک ڈیلیوری کے مسائل سے ہوتا ہے، پھر بھی صرف 23% انجینئرنگ ٹیموں نے ویب ہُک کی نگرانی کے لیے وقف کیا ہے۔ ویب ہکس دھوکہ دہی سے آسان ہیں — ایک سسٹم سے دوسرے سسٹم تک ایک HTTP پوسٹ — لیکن پیداوار میں، وہ لطیف اور مایوس کن طریقوں سے ناکام ہو جاتے ہیں۔

یہ گائیڈ پورے ویب ہُک لائف سائیکل کا احاطہ کرتا ہے: یہ سمجھنے سے لے کر کہ ویب ہکس کیوں ناکام ہو جاتے ہیں، مضبوط ڈیبگنگ ورک فلو بنانے تک، پروڈکشن گریڈ مانیٹرنگ کو نافذ کرنے تک جو آپ کے صارفین سے پہلے مسائل کو پکڑتا ہے۔

اہم نکات

• ویب ہکس خاموشی سے ناکام ہوجاتے ہیں — API کالز کے برعکس جہاں آپ کے کوڈ کو غلطی کا جواب ملتا ہے، ویب ہُک کی ناکامیاں بھیجنے والے کی طرف سے ہوتی ہیں اور آپ کا سسٹم کبھی نہیں جانتا کہ درخواست کی کوشش کی گئی تھی جب تک کہ آپ کی نگرانی نہ ہو۔
• ویب ہک کی پانچ عام ناکامیاں یہ ہیں: اینڈ پوائنٹ ناقابل رسائی (DNS/نیٹ ورک)، SSL سرٹیفکیٹ کے مسائل، ٹائم آؤٹ (پروسیسنگ میں بہت زیادہ وقت لگا)، غلط پے لوڈ پارسنگ، اور دستخط کی توثیق میں ناکامی۔
• Idempotency لازمی ہے — دوبارہ کوشش کرنے کی وجہ سے ویب ہکس ایک سے زیادہ بار ڈیلیور کیے جاسکتے ہیں، اس لیے آپ کے ہینڈلر کو وہی نتیجہ پیش کرنا چاہیے چاہے وہ ایک بار یا دس بار پے لوڈ پر کارروائی کرے۔
• دستخط کی توثیق HMAC-SHA256 کا استعمال کرتے ہوئے ویب ہک سیکیورٹی کے لیے انڈسٹری کا معیار ہے — پروڈکشن میں کبھی بھی غیر تصدیق شدہ پے لوڈز پر کارروائی نہ کریں۔
• سڑکچرڈ لاگنگ اور الرٹنگ منٹوں میں مسائل کو پکڑتے ہیں، جبکہ ڈیڈ لیٹر قطاریں اس بات کو یقینی بناتی ہیں کہ کوئی واقعہ مستقل طور پر ضائع نہ ہو۔

1. ویب ہک آرکیٹیکچر کے بنیادی اصول

ڈیبگ کرنے سے پہلے، سمجھیں کہ کس طرح ویب ہکس سسٹم کے ذریعے بہتے ہیں:

┌──────────┐     HTTP POST      ┌──────────────┐     Queue      ┌──────────────┐
│  Source   │ ──────────────────>│  Your Server │ ────────────>  │  Processor   │
│ (Stripe,  │  Headers + JSON    │  (Receiver)  │  Async job     │  (Handler)   │
│  Shopify) │                    │              │                │              │
└──────────┘                    └──────────────┘                └──────────────┘
      │                                │                               │
      │  Expects 2xx within            │  Verify signature             │  Business logic
      │  5-30 seconds                  │  Parse payload                │  Database writes
      │                                │  Enqueue for processing       │  Trigger side effects
      │  Retries on failure            │  Return 200 immediately       │  Log completion
      └────────────────────────────────┘                               └──────────────────

تنقیدی ڈیزائن کا اصول: ویب ہُک (واپسی 200) کو جتنی جلدی ممکن ہو تسلیم کریں، پھر اس پر غیر متوازی طور پر کارروائی کریں۔ زیادہ تر ویب ہک بھیجنے والوں کے پاس جارحانہ ٹائم آؤٹ (5-30 سیکنڈ) ہوتے ہیں اور اگر آپ کا اختتامی نقطہ وقت پر جواب نہیں دیتا ہے تو وہ دوبارہ کوشش کریں گے۔

2. ویب ہک کی پانچ سب سے عام ناکامیاں

ناکامی 1: اختتامی نقطہ ناقابل رسائی

# Symptoms: Sender shows "connection refused" or "DNS resolution failed"
# Common causes:
# - Firewall blocking the sender's IP range
# - DNS misconfiguration after domain migration
# - Load balancer health check failing
# - Server crashed or not started

# Diagnostic steps:
# 1. Test connectivity from outside your network
curl -X POST https://your-domain.com/webhooks/stripe \
  -H "Content-Type: application/json" \
  -d '{"test": true}' \
  -v  # Verbose output shows connection details

# 2. Check DNS resolution
nslookup your-domain.com
dig your-domain.com +short

# 3. Check if the port is listening
nc -zv your-domain.com 443

# 4. Check firewall rules (if you have server access)
sudo ufw status
sudo iptables -L -n | grep 443

ناکامی 2: SSL سرٹیفکیٹ کے مسائل

# Symptoms: "SSL handshake failed", "certificate expired", "self-signed cert"
# Webhook senders REQUIRE valid SSL certificates

# Check certificate expiry
echo | openssl s_client -servername your-domain.com -connect your-domain.com:443 2>/dev/null | openssl x509 -noout -dates

# Check full certificate chain
openssl s_client -connect your-domain.com:443 -showcerts < /dev/null 2>/dev/null

# Common fix: renew Let's Encrypt certificate
# sudo certbot renew --force-renewal
# sudo systemctl reload nginx

ناکامی 3: ٹائم آؤٹ

# Symptoms: Sender retries because your endpoint took too long
# Solution: Acknowledge immediately, process asynchronously

# BAD: Processing inline (may take 10+ seconds)
@app.route('/webhooks/stripe', methods=['POST'])
def bad_webhook_handler():
    event = parse_stripe_event(request)
    process_payment(event)        # Database queries, external API calls
    send_confirmation_email(event) # SMTP call
    update_inventory(event)        # More database queries
    return jsonify({'status': 'ok'}), 200  # Too late — Stripe already timed out

# GOOD: Acknowledge immediately, process in background
@app.route('/webhooks/stripe', methods=['POST'])
def good_webhook_handler():
    # Verify signature FIRST (fast)
    verify_stripe_signature(request)

    # Enqueue for background processing
    task_queue.enqueue('process_stripe_event', request.json)

    # Return 200 within milliseconds
    return jsonify({'status': 'received'}), 200

ناکامی 4: پے لوڈ پارسنگ کی خرابیاں

# Symptoms: 400/500 errors, "unexpected token", type errors
# Cause: Assumptions about payload structure that break with API updates

# BAD: Assuming structure
def process_order(payload):
    customer_email = payload['data']['object']['customer']['email']  # KeyError!

# GOOD: Defensive parsing
def process_order(payload):
    try:
        data = payload.get('data', {})
        obj = data.get('object', {})
        customer = obj.get('customer', {})

        # Customer might be a string (ID) or an object
        if isinstance(customer, str):
            customer_email = None  # Need to fetch from API
        else:
            customer_email = customer.get('email')

        if not customer_email:
            logger.warning(f"No customer email in webhook: {payload.get('id')}")
            return

    except Exception as e:
        logger.exception(f"Failed to parse webhook payload: {e}")
        raise

ناکامی 5: دستخط کی توثیق میں ناکامی۔

import hmac
import hashlib

def verify_stripe_signature(request):
    """Verify Stripe webhook signature."""
    payload = request.data  # Raw bytes, NOT parsed JSON
    sig_header = request.headers.get('Stripe-Signature', '')
    webhook_secret = os.environ['STRIPE_WEBHOOK_SECRET']

    # Parse the signature header
    elements = dict(item.split('=', 1) for item in sig_header.split(','))
    timestamp = elements.get('t')
    signature = elements.get('v1')

    if not timestamp or not signature:
        raise ValueError('Missing signature components')

    # Compute expected signature
    signed_payload = f'{timestamp}.{payload.decode("utf-8")}'
    expected = hmac.new(
        webhook_secret.encode('utf-8'),
        signed_payload.encode('utf-8'),
        hashlib.sha256
    ).hexdigest()

    if not hmac.compare_digest(expected, signature):
        raise ValueError('Signature verification failed')

    # Check timestamp freshness (prevent replay attacks)
    import time
    tolerance = 300  # 5 minutes
    if abs(time.time() - int(timestamp)) > tolerance:
        raise ValueError('Webhook timestamp too old')

عام دستخط کی توثیق کی غلطیاں:

• تصدیق کرنے سے پہلے JSON کو پارس کرنا (خام جسم کو تبدیل کرتا ہے)
• غلط راز کا استعمال کرنا (ٹیسٹ بمقابلہ لائیو موڈ)
• مستقل وقت کا موازنہ استعمال نہیں کرنا (hmac.compare_digest)
• فریم ورک مڈل ویئر آپ کے ہینڈلر کو دیکھنے سے پہلے درخواست کے باڈی میں ترمیم کرتا ہے۔

3. ڈیبگنگ ٹولز

ngrok — مقامی اختتامی مقامات کو بے نقاب کریں۔

# Install and expose local port
ngrok http 3001

# Output:
# Forwarding https://abc123.ngrok-free.app -> http://localhost:3001
# Use this URL as your webhook endpoint in the sender's dashboard

# ngrok provides a web inspector at http://127.0.0.1:4040
# - See every request/response pair
# - Replay failed webhooks
# - Inspect headers and bodies

webhook.site — فوری جانچ

# 1. Go to https://webhook.site — get a unique URL
# 2. Configure that URL as your webhook endpoint
# 3. Trigger events and see payloads in real-time
# 4. Copy the payload format for your handler development

curl — دستی جانچ

# Simulate a Stripe checkout.session.completed webhook
curl -X POST http://localhost:3001/api/billing/webhook \
  -H "Content-Type: application/json" \
  -H "Stripe-Signature: t=1616161616,v1=abc123..." \
  -d '{
    "id": "evt_test_123",
    "type": "checkout.session.completed",
    "data": {
      "object": {
        "id": "cs_test_456",
        "customer": "cus_test_789",
        "amount_total": 4999,
        "currency": "usd",
        "metadata": {
          "product_id": "42",
          "user_id": "7"
        }
      }
    }
  }'

# Watch for the response status and body

سٹرکچرڈ لاگنگ

import structlog
import json
from datetime import datetime

logger = structlog.get_logger()

def log_webhook_event(request, response_status, processing_time_ms, error=None):
    """Log every webhook with full context for debugging."""
    log_data = {
        'event': 'webhook_received',
        'timestamp': datetime.utcnow().isoformat(),
        'source': detect_webhook_source(request),
        'event_type': request.json.get('type', 'unknown'),
        'event_id': request.json.get('id', 'unknown'),
        'method': request.method,
        'path': request.path,
        'content_length': request.content_length,
        'response_status': response_status,
        'processing_time_ms': processing_time_ms,
        'ip_address': request.remote_addr,
        'user_agent': request.headers.get('User-Agent', ''),
    }

    if error:
        log_data['error'] = str(error)
        log_data['error_type'] = type(error).__name__
        logger.error('webhook_failed', **log_data)
    else:
        logger.info('webhook_processed', **log_data)

4. حکمت عملیوں کی دوبارہ کوشش کریں۔

زیادہ تر ویب ہک بھیجنے والے ایکسپونینشل بیک آف کے ساتھ خودکار دوبارہ کوششیں نافذ کرتے ہیں۔ پٹی 24 گھنٹوں میں 3 بار تک دوبارہ کوشش کرتی ہے۔ Shopify 48 گھنٹوں میں 19 بار دوبارہ کوشش کرتا ہے۔ آپ کے سسٹم کو آئیڈیمپوٹینسی کیز کے ذریعے ڈپلیکیٹ ڈیلیوری کو ہینڈل کرنے کے لیے ڈیزائن کیا جانا چاہیے، اور آپ کو ناکامیوں پر کارروائی کرنے کے لیے اپنی دوبارہ کوشش کی قطار کو لاگو کرنا چاہیے تاکہ ڈیٹا بیس ٹائم آؤٹ جیسی عارضی خرابیاں مستقل طور پر واقعات سے محروم نہ ہوں۔

بھیجنے والے کی دوبارہ کوشش کی پالیسیاں

اپنی خود کی دوبارہ کوشش کی قطار بنانا

// Node.js retry queue with exponential backoff
const Bull = require('bull');

const webhookQueue = new Bull('webhooks', {
  redis: { host: 'localhost', port: 6379 },
  defaultJobOptions: {
    attempts: 5,
    backoff: {
      type: 'exponential',
      delay: 2000, // 2s, 4s, 8s, 16s, 32s
    },
    removeOnComplete: 100,
    removeOnFail: false, // Keep failed jobs for analysis
  },
});

// Producer: enqueue webhook for processing
async function enqueueWebhook(eventType, payload, source) {
  await webhookQueue.add(eventType, {
    payload,
    source,
    receivedAt: new Date().toISOString(),
    idempotencyKey: payload.id || `${source}-${Date.now()}`,
  });
}

// Consumer: process webhooks
webhookQueue.process('checkout.session.completed', async (job) => {
  const { payload, idempotencyKey } = job.data;

  // Check idempotency
  const processed = await redis.get(`webhook:${idempotencyKey}`);
  if (processed) {
    console.log(`Skipping duplicate webhook: ${idempotencyKey}`);
    return { status: 'duplicate', key: idempotencyKey };
  }

  try {
    // Process the event
    await handleCheckoutCompleted(payload);

    // Mark as processed (TTL 48h)
    await redis.setex(`webhook:${idempotencyKey}`, 172800, 'processed');

    return { status: 'success' };
  } catch (error) {
    // Will be retried automatically by Bull
    throw error;
  }
});

// Dead letter handler
webhookQueue.on('failed', (job, error) => {
  if (job.attemptsMade >= job.opts.attempts) {
    console.error(`Webhook permanently failed after ${job.attemptsMade} attempts:`, {
      eventType: job.name,
      idempotencyKey: job.data.idempotencyKey,
      error: error.message,
    });
    // Send alert to Slack/PagerDuty
    alertService.sendCritical('Webhook permanently failed', {
      job: job.id,
      event: job.name,
      error: error.message,
    });
  }
});

5. Idempotency کا نفاذ

import hashlib
import redis

redis_client = redis.Redis(host='localhost', port=6379, db=0)

def process_webhook_idempotently(event_id, event_type, payload, handler_fn):
    """Ensure a webhook is processed exactly once."""
    # Create idempotency key
    idem_key = f"webhook:processed:{event_id}"

    # Check if already processed (atomic operation)
    if redis_client.exists(idem_key):
        logger.info(f"Skipping duplicate webhook: {event_id}")
        return {'status': 'duplicate'}

    # Set a processing lock (prevents concurrent processing)
    lock_key = f"webhook:lock:{event_id}"
    lock_acquired = redis_client.set(lock_key, '1', nx=True, ex=60)

    if not lock_acquired:
        logger.warning(f"Webhook already being processed: {event_id}")
        return {'status': 'in_progress'}

    try:
        # Process the event
        result = handler_fn(event_type, payload)

        # Mark as processed (keep for 48 hours)
        redis_client.setex(idem_key, 172800, json.dumps({
            'processed_at': datetime.utcnow().isoformat(),
            'result': str(result),
        }))

        return {'status': 'processed', 'result': result}

    except Exception as e:
        # Release lock so it can be retried
        redis_client.delete(lock_key)
        raise

    finally:
        redis_client.delete(lock_key)

6. مانیٹرنگ ڈیش بورڈ

ٹریک کرنے کے لیے کلیدی میٹرکس

پرومیتھیس میٹرکس کی مثال

from prometheus_client import Counter, Histogram, Gauge

# Counters
webhook_received_total = Counter(
    'webhook_received_total',
    'Total webhooks received',
    ['source', 'event_type']
)

webhook_processed_total = Counter(
    'webhook_processed_total',
    'Total webhooks successfully processed',
    ['source', 'event_type']
)

webhook_failed_total = Counter(
    'webhook_failed_total',
    'Total webhook processing failures',
    ['source', 'event_type', 'error_type']
)

webhook_duplicate_total = Counter(
    'webhook_duplicate_total',
    'Duplicate webhook deliveries skipped',
    ['source']
)

# Histograms
webhook_processing_duration = Histogram(
    'webhook_processing_duration_seconds',
    'Time to process a webhook',
    ['source', 'event_type'],
    buckets=[0.01, 0.05, 0.1, 0.25, 0.5, 1.0, 2.5, 5.0, 10.0]
)

# Gauges
webhook_queue_depth = Gauge(
    'webhook_queue_depth',
    'Current number of webhooks waiting to be processed',
    ['source']
)

ہیلتھ چیک اینڈ پوائنٹ

// NestJS health check example
@Controller('health')
export class HealthController {
  @Get('webhooks')
  async webhookHealth() {
    const stats = await this.webhookService.getStats();

    const healthy = stats.failureRate < 0.02
      && stats.queueDepth < 500
      && stats.avgProcessingTimeMs < 2000
      && stats.deadLetterCount < 10;

    return {
      status: healthy ? 'healthy' : 'degraded',
      metrics: {
        totalReceived24h: stats.totalReceived,
        successRate: `${((1 - stats.failureRate) * 100).toFixed(2)}%`,
        avgProcessingTimeMs: stats.avgProcessingTimeMs,
        queueDepth: stats.queueDepth,
        deadLetterCount: stats.deadLetterCount,
        duplicateRate: `${(stats.duplicateRate * 100).toFixed(2)}%`,
        lastReceivedAt: stats.lastReceivedAt,
      },
    };
  }
}

7. سیکیورٹی کے بہترین طریقے

IP وائٹ لسٹنگ

# Nginx configuration for webhook endpoints
location /api/webhooks/stripe {
    # Only allow Stripe's IP ranges
    # https://stripe.com/docs/ips
    allow 3.18.12.63;
    allow 3.130.192.0/24;
    allow 13.235.14.0/24;
    allow 18.211.135.0/24;
    allow 35.154.171.0/24;
    deny all;

    proxy_pass http://localhost:3001;
}

توثیق کی چیک لسٹ کی درخواست کریں۔

1. کرپٹوگرافک دستخط کی تصدیق کریں (HMAC-SHA256)
2. چیک کریں کہ ٹائم اسٹیمپ رواداری کے اندر ہے (5 منٹ)
3. مواد کی قسم ہیڈر کی توثیق کریں۔
4. چیک کریں کہ پے لوڈ کا سائز حد کے اندر ہے (مسترد کریں> 1MB)
5. متوقع واقعہ کی قسم کی توثیق کریں۔
6. آئی پی ایڈریس کی تصدیق کریں اگر بھیجنے والا رینج شائع کرتا ہے۔
7. اختتامی نقطہ کی شرح کو محدود کریں (غلط استعمال کو روکیں)

def validate_webhook_request(request):
    """Comprehensive webhook request validation."""
    errors = []

    # 1. Content-Type
    if request.content_type != 'application/json':
        errors.append(f'Invalid Content-Type: {request.content_type}')

    # 2. Payload size (max 1MB)
    if request.content_length and request.content_length > 1_048_576:
        errors.append(f'Payload too large: {request.content_length} bytes')

    # 3. Required headers
    if not request.headers.get('X-Webhook-Signature'):
        errors.append('Missing signature header')

    # 4. Valid JSON
    try:
        payload = request.json
    except Exception:
        errors.append('Invalid JSON payload')
        return errors

    # 5. Required fields
    if 'type' not in payload:
        errors.append('Missing event type')
    if 'id' not in payload:
        errors.append('Missing event ID')

    return errors

8. ڈیبگنگ چیک لسٹ

جب ویب ہک کام کرنا چھوڑ دیتا ہے، تو اس منظم طریقے پر عمل کریں:

1. بھیجنے والے کا ڈیش بورڈ چیک کریں — زیادہ تر پلیٹ فارمز (سٹرائپ، Shopify، GitHub) ڈیلیوری کی کوششیں، رسپانس کوڈز اور ٹائم اسٹیمپ دکھاتے ہیں
2. اپنے سرور لاگز کو چیک کریں — Nginx/Apache میں ویب ہک اینڈ پوائنٹ تک رسائی کے لاگز تلاش کریں۔
3. SSL سرٹیفکیٹ کی تصدیق کریں — ایکسپائرڈ سرٹیفکیٹ نمبر ایک خاموش قاتل ہیں۔
4. کرل کے ساتھ ٹیسٹ کریں — ایک مختلف نیٹ ورک سے اپنے اختتامی نقطہ پر دستی طور پر پوسٹ کریں۔
5. DNS ریزولوشن چیک کریں — یقینی بنائیں کہ آپ کا ڈومین بیرونی نیٹ ورکس سے درست طریقے سے حل کرتا ہے
6. ویب ہک راز کی تصدیق کریں — راز کلیدی تبدیلیوں یا ماحول کی منتقلی کے دوران گھومتے ہیں
7. پے لوڈ فارمیٹ کی تبدیلیوں کو چیک کریں — API ورژن اپ ڈیٹ ویب ہک پے لوڈز کو تبدیل کر سکتے ہیں
8. حالیہ تعیناتیوں کا جائزہ لیں — کوڈ کی تبدیلیوں سے ہینڈلر ٹوٹ سکتا ہے۔
9. وسائل کی حدود چیک کریں — میموری، CPU، ڈیٹا بیس کنکشن
10. مکمل پروسیسنگ پائپ لائن کی جانچ کریں — ڈیٹا بیس کی تحریروں کی تصدیق کریں، قطار کی پروسیسنگ، ضمنی اثرات

اکثر پوچھے گئے سوالات

میں مقامی ترقی میں ویب ہکس کی جانچ کیسے کروں؟

اپنے مقامی سرور کو انٹرنیٹ پر بے نقاب کرنے کے لیے ngrok یا اسی طرح کے ٹنلنگ ٹول کا استعمال کریں۔ ایک عوامی URL حاصل کرنے کے لیے 'ngrok HTTP 3001' چلائیں جو لوکل ہوسٹ:3001 کو فارورڈ کرتا ہے۔ اس URL کو بھیجنے والے کے ڈیش بورڈ میں ویب ہک اینڈ پوائنٹ کے بطور کنفیگر کریں۔ لوکل ہوسٹ:4040 پر اینگروک ویب انسپکٹر آپ کو ہر درخواست کا معائنہ کرنے اور ناکام ڈیلیوری کو دوبارہ چلانے دیتا ہے۔ CI/CD کے لیے، اس کے بجائے فرضی سرورز یا ریکارڈ ری پلے پیٹرن استعمال کریں۔

میرے ویب ہک اینڈ پوائنٹ کو کیا واپس کرنا چاہیے؟

200 اسٹیٹس کوڈ جلد از جلد واپس کریں — 2-5 سیکنڈ کے اندر۔ عام طور پر بھیجنے والے کی طرف سے جوابی مواد کو نظر انداز کیا جاتا ہے، لیکن ایک سادہ JSON جیسا کہ {"status":"received"} اچھا عمل ہے۔ 200 واپس کریں یہاں تک کہ اگر آپ ایونٹ کو متضاد طور پر پروسیس کرنے کا ارادہ رکھتے ہیں۔ صرف 4xx واپس کریں اگر دستخط غلط ہے یا پے لوڈ خراب ہے۔ کاروباری منطق کی غلطیوں کے لیے کبھی بھی 5xx واپس نہ کریں — ان کو لاگ کریں اور اس کے بجائے دوبارہ کوشش کی قطار میں کارروائی کریں۔

میں ویب ہک ایونٹس کو کیسے ہینڈل کروں جو کہ ترتیب سے باہر ہو؟

دوبارہ کوششوں اور نیٹ ورک کے حالات کی وجہ سے ایونٹس ٹھیک سے باہر ہو سکتے ہیں۔ اپنے ہینڈلر میں ٹائم اسٹیمپ یا ترتیب نمبر چیک شامل کریں۔ اسٹرائپ کے لیے، ایونٹ کا بنایا ہوا ٹائم اسٹیمپ استعمال کریں۔ Shopify کے لیے اپڈیٹڈ_اٹ فیلڈ کو چیک کریں۔ اگر کوئی ایسا واقعہ آتا ہے جس سے مراد ایسی حالت ہے جو آپ کے سسٹم نے ابھی تک نہیں دیکھی ہے، یا تو اسے بعد میں پروسیسنگ کے لیے قطار میں لگائیں یا مصالحت کے لیے بھیجنے والے کے API سے موجودہ حالت حاصل کریں۔ Idempotency چابیاں ڈپلیکیٹ پروسیسنگ کو روکتی ہیں قطع نظر آرڈر کے۔

ویب ہک کی وشوسنییتا کی نگرانی کا بہترین طریقہ کیا ہے؟

چار کلیدی میٹرکس کو ٹریک کریں: ڈیلیوری کی کامیابی کی شرح (99.5% سے اوپر)، پروسیسنگ کا اوسط وقت (500 ملی سیکنڈ سے کم ہدف)، قطار کی گہرائی (100 سے کم ہدف)، اور ڈیڈ لیٹر قطار کا سائز (ہدف صفر)۔ جب کوئی میٹرک اپنی حد سے تجاوز کرتا ہے تو انتباہات مرتب کریں۔ ڈیش بورڈز کے لیے Grafana کے ساتھ Prometheus استعمال کریں، یا Datadog یا New Relic جیسی منظم سروس۔ ڈیلیوری کی ناکامیوں کے لیے بھیجنے والے کے ویب ہُک ڈیش بورڈ کی بھی نگرانی کریں جو آپ اپنے لاگز میں نہیں دیکھ سکتے۔

میں ویب ہک ری پلے حملوں کو کیسے روک سکتا ہوں؟

تین دفاع کو لاگو کریں: سب سے پہلے، مشترکہ راز کے ساتھ HMAC-SHA256 کا استعمال کرتے ہوئے ہر درخواست پر کرپٹوگرافک دستخط کی تصدیق کریں۔ دوسرا، دستخط شدہ پے لوڈ میں ٹائم اسٹیمپ چیک کریں اور 5 منٹ سے زیادہ پرانے ایونٹس کو مسترد کریں (سٹرائپ میں یہ ان کی دستخطی اسکیم میں شامل ہے)۔ تیسرا، یہ یقینی بنانے کے لیے آئیڈیمپوٹینسی کلیدیں استعمال کریں کہ ہر ایونٹ پر ایک بار کارروائی ہوتی ہے، چاہے حملہ آور ٹائم اسٹیمپ ونڈو کے اندر درست دستخط شدہ درخواست کو دوبارہ چلائے۔

اگلے اقدامات

ویب ہُک کی وشوسنییتا ایونٹ سے چلنے والے انضمام کی بنیاد ہے۔ اس گائیڈ میں پیٹرن — دستخط کی توثیق، آئیڈیمپوٹینٹ پروسیسنگ، async قطاریں، ساختی نگرانی — لاگو ہوتے ہیں قطع نظر اس کے کہ آپ کس پلیٹ فارم کو ضم کر رہے ہیں۔

متعلقہ وسائل:

• Odoo REST API ٹیوٹوریل — Odoo کے ساتھ API کا انضمام
• ECOSIRE Marketplace Connectors — پہلے سے تعمیر شدہ Odoo انضمام
• ای کامرس 2026 کے لیے بہترین ERP — انٹیگریشن کے لیے تیار ERP موازنہ

ECOSIRE پروڈکشن گریڈ ویب ہک انٹیگریشن بناتا ہے جو Odoo, Shopify, Stripe اور درجنوں دیگر پلیٹ فارمز کو جوڑتا ہے۔ ہماری انٹیگریشن سروسز میں مانیٹرنگ ڈیش بورڈز، ڈیڈ لیٹر کیو ہینڈلنگ، اور 99.9% ڈیلیوری کی ضمانتیں شامل ہیں۔ ہمارے انٹیگریشن انجینئرز سے بات کریں۔