# Webhook Adalah: Pengertian, Cara Kerja, dan Contohnya

> Webhook adalah kiriman HTTP otomatis saat sebuah peristiwa terjadi. Pahami cara kerja, beda dengan API, contoh di payment gateway & WhatsApp, dan keamanannya.

**URL:** https://www.ciptadusa.com/blog/webhook-adalah  
**Type:** blog  
**Author:** PT Cipta Dua Saudara  
**Category:** Teknologi  
**Published:** 2026-10-29  
**Cover:** https://www.ciptadusa.com/media/uploads/blog/2026-10/1793240507634-webhook-adalah-20261029.webp  

## Article

Webhook adalah permintaan HTTP otomatis yang dikirim sebuah aplikasi ke URL milik aplikasi lain begitu peristiwa tertentu terjadi, misalnya pembayaran lunas, pesan WhatsApp masuk, atau kode baru di-push ke repositori. GitHub Docs menjelaskan bahwa webhook membuat Anda bisa berlangganan peristiwa di sebuah sistem dan menerima kiriman data ke server secara otomatis saat peristiwa itu terjadi, berbeda dengan polling API yang memanggil API berulang kali untuk mengecek apakah ada data baru ([sumber](https://docs.github.com/en/webhooks/about-webhooks)).

Dokumentasi WhatsApp Business Platform dari Meta memakai definisi yang serupa: webhook adalah permintaan HTTP berisi payload JSON yang dikirim server Meta ke server pilihan Anda untuk memberi tahu pesan masuk, status pesan keluar, dan perubahan penting lain ([sumber](https://developers.facebook.com/docs/whatsapp/cloud-api/guides/set-up-webhooks)). Artikel ini membahas pengertian webhook, cara kerjanya, perbedaannya dengan API, contoh di payment gateway, WhatsApp, Telegram, GitHub, dan n8n, cara mengamankan endpoint webhook, serta checklist sebelum memakainya di sistem bisnis.

## Pengertian Webhook

Microsoft Learn menyebut webhook sebagai sebuah pola, bukan produk tertentu. Penerapannya berbeda di tiap layanan, tetapi idenya sama: webhook dapat dianggap model publish/subscribe sederhana, tempat pengguna berlangganan peristiwa yang terjadi di sistem lain, lalu pemberitahuan peristiwa dikirim sebagai permintaan HTTP POST yang berisi informasi peristiwa tersebut ([sumber](https://learn.microsoft.com/id-id/aspnet/webhooks/)).

Analogi sederhananya (penyederhanaan CDS): polling API mirip menelepon kurir setiap 10 menit untuk menanyakan apakah paket sudah sampai. Webhook mirip meninggalkan alamat dan nomor telepon, lalu kurir yang mengabari begitu paket tiba. Alamat itu adalah URL webhook, dan kabar dari kurir adalah payload.

### Istilah Penting dalam Webhook

| Istilah | Arti |
| --- | --- |
| Event (peristiwa) | Perubahan di sistem pengirim yang memicu webhook, misalnya pembayaran berhasil atau pesan baru |
| Webhook URL / endpoint | Alamat HTTPS di server penerima yang didaftarkan untuk menerima kiriman |
| Payload | Isi kiriman (Meta dan Midtrans memakai JSON) yang menjelaskan peristiwa yang terjadi |
| Secret / signature | Kunci rahasia dan tanda tangan digital untuk membuktikan kiriman benar dari pengirim yang sah |
| Retry | Pengiriman ulang otomatis oleh pengirim bila penerima tidak membalas dengan status sukses |
| Callback | Istilah lain yang dipakai sebagian penyedia, misalnya Xendit memakai header x-callback-token untuk kiriman webhook-nya |

## Cara Kerja Webhook

Menurut Microsoft Learn, alur webhook berjalan dalam tiga bagian: pengirim membuka daftar peristiwa yang bisa diikuti, penerima mendaftarkan webhook, lalu saat peristiwa terjadi pengirim mencari pendaftaran yang cocok dan mengirim permintaan HTTP POST. Pendaftaran webhook terdiri dari URL tujuan, filter peristiwa, kunci rahasia untuk menandatangani permintaan, dan data tambahan bila diperlukan ([sumber](https://learn.microsoft.com/id-id/aspnet/webhooks/)).

Urutan praktisnya:

1. **Daftarkan URL.** Tim Anda membuat endpoint, misalnya `https://contoh.co.id/webhook/pembayaran`, lalu memasukkannya ke dashboard atau API penyedia.
2. **Pilih peristiwa.** GitHub menyarankan berlangganan hanya ke peristiwa yang benar-benar dibutuhkan agar beban server berkurang ([sumber](https://docs.github.com/en/webhooks/using-webhooks/best-practices-for-using-webhooks)).
3. **Peristiwa terjadi.** Pelanggan membayar, pesan masuk, atau status pesanan berubah.
4. **Pengirim mengirim POST.** Body berisi payload JSON, header berisi informasi seperti jenis peristiwa, ID pengiriman, dan tanda tangan.
5. **Penerima membalas 2xx.** Balasan sukses menandakan kiriman sudah diterima. GitHub meminta server membalas dengan status 2XX dalam 10 detik, jika lebih lama koneksi diputus dan pengiriman dianggap gagal ([sumber](https://docs.github.com/en/webhooks/using-webhooks/best-practices-for-using-webhooks)).
6. **Proses di latar belakang.** Agar bisa membalas cepat, GitHub menyarankan payload dimasukkan ke antrean (queue) lalu diproses secara asinkron ([sumber](https://docs.github.com/en/webhooks/using-webhooks/best-practices-for-using-webhooks)).

### Contoh Payload Webhook

Berikut potongan payload webhook WhatsApp dari dokumentasi Meta saat pelanggan mengirim pesan teks ke nomor bisnis (disingkat):

```json
{
  "object": "whatsapp_business_account",
  "entry": [
    {
      "changes": [
        {
          "field": "messages",
          "value": {
            "messages": [
              {
                "from": "16505551234",
                "type": "text",
                "text": { "body": "Does it come in another color?" }
              }
            ]
          }
        }
      ]
    }
  ]
}
```

Sumber contoh: [dokumentasi webhook WhatsApp](https://developers.facebook.com/docs/whatsapp/cloud-api/guides/set-up-webhooks). Struktur payload berbeda di tiap penyedia, sehingga penerima harus membaca dokumentasi masing-masing sebelum memetakan field ke database.

## Perbedaan Webhook dan API

Webhook dan API bukan pilihan yang saling meniadakan. Webhook tetap berjalan di atas HTTP dan penerimanya pada dasarnya adalah endpoint API milik Anda. Bedanya ada pada siapa yang memulai komunikasi. Konsep API secara umum dibahas di artikel [API adalah](/blog/api-adalah).

| Aspek | API (request-response / polling) | Webhook |
| --- | --- | --- |
| Siapa yang memulai | Aplikasi Anda mengirim request | Sistem penyedia mengirim POST ke URL Anda |
| Waktu data diterima | Saat Anda memanggil | Saat peristiwa terjadi |
| Beban | Banyak panggilan bisa kosong bila tidak ada data baru | Kiriman hanya ada bila ada peristiwa |
| Cocok untuk | Mengambil data sesuai kebutuhan, membuat atau mengubah data | Notifikasi pembayaran, pesan masuk, perubahan status |
| Risiko utama | Batas jumlah request (rate limit) | Kiriman ganda, urutan acak, kiriman palsu |

GitHub mencatat tiga keunggulan webhook dibanding polling: butuh usaha dan sumber daya lebih kecil, lebih mudah diskalakan karena tidak perlu memanggil API untuk setiap resource sampai menyentuh batas rate limit, dan memberi pembaruan hampir real-time. Sebaliknya, jika data hanya dibutuhkan sesekali atau dari sedikit resource, memanggil API saat diperlukan sudah cukup ([sumber](https://docs.github.com/en/webhooks/about-webhooks)).

Dalam praktik, keduanya dipakai bersama. Midtrans, misalnya, mengirim notifikasi HTTP POST saat status transaksi berubah, tetapi juga menyarankan memanggil GET Status API bila notifikasi terlambat atau datang tidak berurutan ([sumber](https://docs.midtrans.com/docs/https-notification-webhooks)). Pola integrasi yang lebih luas, termasuk ETL dan middleware, ada di artikel [integrasi sistem adalah](/blog/integrasi-sistem-adalah) dan [middleware adalah](/blog/middleware-adalah).

## Contoh Penggunaan Webhook

### Webhook Payment Gateway

Midtrans mengirim notifikasi HTTP(S) POST ke server Anda saat pelanggan menyelesaikan pembayaran atau saat status transaksi berubah, dan URL tujuannya diatur lewat Payment Notification URL di dashboard ([sumber](https://docs.midtrans.com/docs/https-notification-webhooks)). Untuk menyatakan transaksi sukses, Midtrans meminta tiga field dicek: status_code bernilai 200, fraud_status bernilai accept bila field itu ada, dan transaction_status bernilai settlement atau capture ([sumber](https://docs.midtrans.com/docs/https-notification-webhooks)).

Midtrans juga menegaskan bahwa data callback dari frontend, misalnya callback JavaScript Snap.js, bisa diubah oleh pengguna sehingga harus diverifikasi lewat API ke Midtrans ([sumber](https://docs.midtrans.com/docs/https-notification-webhooks)). Artinya, status lunas di sistem Anda sebaiknya ditentukan oleh webhook yang sudah diverifikasi di backend, bukan oleh halaman "terima kasih" di browser.

Xendit menjelaskan alasan webhook dibutuhkan dalam pembayaran: banyak metode pembayaran memerlukan autentikasi pengguna secara asinkron, dan metode pembayaran lokal bisa diproses dalam hitungan jam hingga hari ([sumber](https://docs.xendit.co/docs/handling-webhooks)).

### Webhook WhatsApp

WhatsApp Business Platform memakai webhook untuk mengabarkan pesan masuk, status pesan keluar, peristiwa panggilan, perubahan status akun, dan perubahan skor kualitas template ([sumber](https://developers.facebook.com/docs/whatsapp/cloud-api/guides/set-up-webhooks)). Saat konfigurasi, Meta mengirim permintaan GET verifikasi berisi hub.mode, hub.challenge, dan hub.verify_token. Endpoint harus mencocokkan verify token dengan yang Anda isi di App Dashboard lalu membalas dengan nilai hub.challenge ([sumber](https://developers.facebook.com/docs/graph-api/webhooks/getting-started)).

Webhook inilah yang menjadi dasar chatbot, inbox tim CS, dan CRM WhatsApp. Contoh penerapannya ada di artikel [cara handle ratusan chat WA tanpa menambah CS](/blog/cara-handle-ratusan-chat-wa-tanpa-menambah-cs).

### Webhook Telegram

Bot Telegram punya dua cara menerima pembaruan yang saling eksklusif: getUpdates (polling) atau setWebhook. Selama webhook aktif, bot tidak bisa menerima pembaruan lewat getUpdates. Port yang didukung untuk webhook adalah 443, 80, 88, dan 8443, dan parameter secret_token membuat setiap kiriman membawa header X-Telegram-Bot-Api-Secret-Token ([sumber](https://core.telegram.org/bots/api#setwebhook)).

### Webhook GitHub untuk CI/CD

GitHub mencontohkan webhook untuk memicu pipeline CI di server eksternal saat kode di-push, mengirim notifikasi ke Slack atau Discord, memperbarui issue tracker seperti Jira, deploy ke server produksi, dan mencatat peristiwa untuk audit ([sumber](https://docs.github.com/en/webhooks/about-webhooks)). Alur rilis otomatis seperti ini termasuk praktik yang dibahas di [DevOps adalah](/blog/devops-adalah).

### Webhook di n8n

Di n8n, node Webhook menjadi pemicu workflow dan punya dua URL: test URL untuk mencoba dan melihat data langsung di editor, serta production URL yang aktif setelah workflow dipublikasikan. Ukuran payload maksimum 16 MB, dan endpoint bisa dilindungi dengan Basic auth, Header auth, atau JWT auth ([sumber](https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.webhook/)).

### Contoh Alur di Perusahaan Distribusi (Ilustrasi)

Contoh berikut adalah ilustrasi, bukan studi kasus klien:

1. Pelanggan membayar invoice lewat virtual account.
2. Payment gateway mengirim webhook ke backend perusahaan.
3. Backend memverifikasi signature, mencatat ID peristiwa, membalas 200, lalu memasukkan pekerjaan ke antrean.
4. Worker mengubah status invoice di [ERP](/blog/erp-adalah) menjadi lunas dan memicu perintah kirim ke gudang.
5. [CRM](/blog/crm-adalah) menerima riwayat transaksi, lalu pelanggan mendapat konfirmasi lewat WhatsApp.

## Cara Membuat Endpoint Webhook

Endpoint webhook adalah route biasa di [backend](/blog/backend-adalah) yang menerima POST. Contoh sederhana di Node.js dengan Express untuk memverifikasi signature HMAC SHA-256 bergaya header X-Hub-Signature-256 (dipakai GitHub dan Meta). Ini contoh penyederhanaan, bukan kode siap produksi:

```js
import express from "express";
import crypto from "node:crypto";

const app = express();

app.post("/webhook/github", express.raw({ type: "application/json" }), (req, res) => {
  const signature = req.get("X-Hub-Signature-256") || "";
  const expected = "sha256=" + crypto
    .createHmac("sha256", process.env.WEBHOOK_SECRET)
    .update(req.body)
    .digest("hex");

  const valid = signature.length === expected.length &&
    crypto.timingSafeEqual(Buffer.from(signature), Buffer.from(expected));
  if (!valid) return res.status(401).send("invalid signature");

  const deliveryId = req.get("X-GitHub-Delivery");
  // simpan deliveryId, abaikan jika sudah pernah diproses
  // masukkan payload ke antrean untuk diproses di latar belakang
  res.status(200).send("ok");
});
```

Beberapa hal dari contoh di atas:

- Signature dihitung dari raw body. Stripe menulis bahwa verifikasi signature butuh raw body request, dan setiap perubahan pada raw body oleh framework membuat verifikasi gagal ([sumber](https://docs.stripe.com/webhooks)).
- GitHub menjelaskan proses validasi memakai secret webhook dan header X-Hub-Signature-256 ([sumber](https://docs.github.com/en/webhooks/using-webhooks/validating-webhook-deliveries)).
- Header X-GitHub-Delivery dapat dipakai untuk melindungi dari replay attack karena unik per peristiwa ([sumber](https://docs.github.com/en/webhooks/using-webhooks/best-practices-for-using-webhooks)).
- Meta menandatangani payload dengan SHA256 menggunakan App Secret dan menaruhnya di header X-Hub-Signature-256 dengan awalan sha256= ([sumber](https://developers.facebook.com/docs/graph-api/webhooks/getting-started)).

Penyedia lain memakai cara berbeda. Midtrans menyertakan signature_key yang dihitung dari SHA512(order_id+status_code+gross_amount+ServerKey) ([sumber](https://docs.midtrans.com/docs/https-notification-webhooks)), sedangkan Xendit mengirim token di header x-callback-token ([sumber](https://docs.xendit.co/docs/handling-webhooks)). Telegram memakai header X-Telegram-Bot-Api-Secret-Token ([sumber](https://core.telegram.org/bots/api#setwebhook)).

## Keamanan dan Keandalan Webhook

URL webhook terbuka ke internet, sehingga siapa pun yang mengetahuinya bisa mengirim request palsu. Stripe menulis bahwa tanpa verifikasi, penyerang dapat mengirim peristiwa palsu untuk memicu aksi seperti memproses pesanan, memberi akses akun, atau mengubah data ([sumber](https://docs.stripe.com/webhooks)).

### Verifikasi Asal Kiriman

- Pakai secret acak dengan entropi tinggi dan simpan dengan aman. Jangan menaruh API key atau kredensial di URL webhook ([sumber](https://docs.github.com/en/webhooks/using-webhooks/best-practices-for-using-webhooks)).
- Gunakan HTTPS. Meta tidak mendukung sertifikat self-signed untuk endpoint webhook ([sumber](https://developers.facebook.com/docs/graph-api/webhooks/getting-started)).
- Tangani webhook di server, bukan di aplikasi klien. Xendit menjelaskan bahwa membuka data dan endpoint webhook ke sisi klien menaikkan risiko manipulasi data dan man-in-the-middle ([sumber](https://docs.xendit.co/docs/handling-webhooks)).
- Bila penyedia menerbitkan daftar IP, allow list bisa menjadi lapisan tambahan. GitHub menyediakan daftar IP lewat endpoint GET /meta dan meminta daftar itu diperbarui berkala ([sumber](https://docs.github.com/en/webhooks/using-webhooks/best-practices-for-using-webhooks)).

### Kiriman Ganda dan Idempotensi

Pengirim akan mengulang kiriman bila tidak menerima balasan sukses, sehingga penerima bisa menerima peristiwa yang sama lebih dari sekali. Stripe menyarankan mencatat ID peristiwa yang sudah diproses dan melewati yang sudah tercatat ([sumber](https://docs.stripe.com/webhooks)). Midtrans menyarankan penanganan notifikasi yang idempoten, salah satunya dengan order_id sebagai kunci ([sumber](https://docs.midtrans.com/docs/https-notification-webhooks)). Xendit menyediakan ID unik seperti payment_id dan capture_id untuk tujuan yang sama ([sumber](https://docs.xendit.co/docs/handling-webhooks)).

### Urutan Kiriman Tidak Dijamin

Stripe tidak menjamin peristiwa dikirim sesuai urutan terjadinya ([sumber](https://docs.stripe.com/webhooks)). Xendit menyebut webhook bisa datang dengan urutan acak karena masalah jaringan atau latensi, dan merekomendasikan message queue sebagai penyangga ([sumber](https://docs.xendit.co/docs/handling-webhooks)). Midtrans menyebut kasus status settlement datang sebelum pending, dan menyarankan memanggil GET Status API untuk mengambil status terbaru ([sumber](https://docs.midtrans.com/docs/https-notification-webhooks)).

### Retry dan Batas Waktu di Beberapa Penyedia

| Penyedia | Batas waktu respons | Perilaku retry |
| --- | --- | --- |
| GitHub | Balas 2XX dalam 10 detik | Kiriman yang terlewat dapat dikirim ulang (redeliver) setelah server pulih ([sumber](https://docs.github.com/en/webhooks/using-webhooks/best-practices-for-using-webhooks)) |
| Midtrans | Menunggu hingga 15 detik, idealnya dibalas dalam 5 detik | Maksimal 5 kali dengan jeda 2 menit, 10 menit, 30 menit, 90 menit, dan 210 menit ([sumber](https://docs.midtrans.com/docs/https-notification-webhooks)) |
| Stripe | Balas 2xx dengan cepat sebelum logika yang rumit | Mode live: dicoba hingga tiga hari dengan exponential back off ([sumber](https://docs.stripe.com/webhooks)) |
| Xendit | Balas 2xx dengan cepat | Hingga enam kali dengan exponential backoff ([sumber](https://docs.xendit.co/docs/handling-webhooks)) |
| Meta (Graph API) | Balas 200 OK | Dicoba ulang selama 36 jam, lalu dibuang ([sumber](https://developers.facebook.com/docs/graph-api/webhooks/getting-started)) |

Midtrans juga membedakan retry berdasarkan kode status: 2XX tidak diulang, 500 diulang sekali, 503 empat kali, 400/404 dua kali, dan 301/302/303 tidak diulang ([sumber](https://docs.midtrans.com/docs/https-notification-webhooks)). Jadi kode status balasan bukan sekadar formalitas.

### Parsing yang Toleran terhadap Field Baru

Midtrans meminta penerima mem-parsing JSON secara tidak ketat agar field baru di masa depan tidak membuat parser error ([sumber](https://docs.midtrans.com/docs/https-notification-webhooks)). GitHub juga meminta aplikasi memeriksa jenis peristiwa dan action sebelum memproses payload karena jenis peristiwa baru terus ditambahkan ([sumber](https://docs.github.com/en/webhooks/using-webhooks/best-practices-for-using-webhooks)).

## Checklist Sebelum Memakai Webhook di Sistem Bisnis

Checklist ini adalah panduan internal CDS:

- Daftar peristiwa yang benar-benar dibutuhkan, beserta aksi bisnis untuk setiap peristiwa.
- Tetapkan sistem mana yang menjadi sumber kebenaran untuk setiap data, misalnya status pembayaran di payment gateway dan status stok di ERP.
- Siapkan endpoint HTTPS, verifikasi signature atau token, dan simpan secret di tempat yang aman.
- Balas 2xx secepatnya, lalu proses payload di antrean.
- Catat ID peristiwa untuk mencegah proses ganda.
- Siapkan rekonsiliasi lewat API untuk menangani kiriman yang terlambat, hilang, atau tidak berurutan.
- Simpan log kiriman dan pasang notifikasi bila endpoint gagal berulang.
- Uji skenario gagal sebelum go-live: signature salah, kiriman ganda, server mati, dan payload dengan field baru. Pengujian bersama pengguna dibahas di [UAT adalah](/blog/uat-adalah).
- Anggarkan pemeliharaan karena penyedia dapat mengubah format payload. Lihat [biaya maintenance aplikasi](/blog/biaya-maintenance-aplikasi).

## Webhook di Proyek CDS

Di [layanan pembuatan software custom](/services/software), CDS membangun aplikasi web, aplikasi mobile, dashboard internal, dan integrasi API, dengan REST API dan webhook sebagai bagian dari stack. Untuk perusahaan yang aplikasinya sudah banyak, [layanan konsultasi IT](/services/consulting) mencakup audit ketergantungan antar sistem dan desain arsitektur target, termasuk integrasi dan keamanan.

CDS juga mengembangkan [Zetta CRM](/incubating/zetta-crm), produk inkubasi berupa server MCP berbasis Go untuk AI agent, dengan outbound Email, WhatsApp, dan Threads lewat satu backend serta endpoint POST /mcp yang dijaga API key.

## FAQ Seputar Webhook

### Webhook adalah apa dalam bahasa sederhana?

Webhook adalah cara sebuah aplikasi mengabari aplikasi lain secara otomatis saat sesuatu terjadi, dengan mengirim data ke alamat URL yang sudah didaftarkan. Penerima tidak perlu bertanya berulang kali.

### Apa itu webhook URL?

Webhook URL adalah alamat endpoint di server penerima, misalnya `https://contoh.co.id/webhook/pembayaran`, yang didaftarkan di dashboard penyedia. Ke alamat inilah penyedia mengirim permintaan POST setiap kali peristiwa yang dipilih terjadi.

### Apa perbedaan webhook dan API?

Pada API, aplikasi Anda yang memulai request. Pada webhook, sistem penyedia yang mengirim data ke URL Anda saat peristiwa terjadi ([sumber](https://docs.github.com/en/webhooks/about-webhooks)). Integrasi bisnis dapat memakai keduanya: webhook untuk notifikasi, API untuk mengambil detail atau mengecek ulang status.

### Apakah webhook aman?

Webhook aman bila endpoint memakai HTTPS, memverifikasi signature atau token dari penyedia, tidak menaruh kredensial di URL, dan memproses kiriman secara idempoten ([sumber](https://docs.github.com/en/webhooks/using-webhooks/best-practices-for-using-webhooks), [sumber](https://docs.stripe.com/webhooks)).

### Apa yang terjadi jika server penerima mati?

Penyedia akan mencoba mengirim ulang sesuai kebijakannya. Stripe mencoba hingga tiga hari di mode live ([sumber](https://docs.stripe.com/webhooks)), Midtrans maksimal lima kali ([sumber](https://docs.midtrans.com/docs/https-notification-webhooks)), dan GitHub menyarankan redeliver kiriman yang terlewat setelah server pulih ([sumber](https://docs.github.com/en/webhooks/using-webhooks/best-practices-for-using-webhooks)). Sistem tetap perlu rekonsiliasi lewat API.

### Apakah webhook bisa dipakai tanpa coding?

Bisa untuk alur sederhana. Node Webhook di n8n menyediakan URL yang dapat memicu workflow ([sumber](https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.webhook/)). Untuk alur yang menyangkut uang, stok, atau data pelanggan, verifikasi, idempotensi, dan logging tetap harus dirancang.

## Butuh Integrasi Webhook untuk Sistem Bisnis Anda?

Jika payment gateway, WhatsApp, toko online, CRM, atau ERP Anda belum saling terhubung, tim CDS bisa membantu merancang alur peristiwanya, membangun endpoint webhook yang terverifikasi, dan menyiapkan rekonsiliasi lewat API. Mulai dari [jasa pembuatan software custom](/services/software), diskusikan arsitekturnya lewat [konsultasi IT](/services/consulting), atau lihat dulu [karya CDS](/works).


---

*Markdown version of https://www.ciptadusa.com/blog/webhook-adalah — generated for AI agents and LLM crawlers.*