Step-by-Step Guide to Implementing Society Webhook Endpoints in Housing Societies
By Sandip Gupta — 2026-09-01
A webhook lets one system tell another when something happens, by sending a message to a web address.
In short: a webhook lets one system tell another when something happens, by sending a message to a web address. For housing societies, webhooks matter when you want society data to reach another system, such as your own reporting tool. This guide explains what webhooks are, what you need before setting one up, how myKutir's webhook endpoints work, how to test them and the best practices to follow.
What is a webhook?
A webhook is a message one system sends to another when an event happens. Instead of your system asking "anything new?" every few minutes, the source system sends a message to an address you choose as soon as there is something to report.
Prerequisites
- A receiving system: a web address (URL) that can accept messages, run by your society's IT support or a vendor.
- A clear purpose: which events you need, and what the receiving system will do with them.
- Security: a way to check that messages really came from the sender.
- Data protection: only send personal data that the purpose requires, in line with the DPDP Act, 2023.
How do webhook endpoints work in myKutir?
- Webhook endpoints are set up for a society by the myKutir team, with the receiving URL and the events it should receive.
- Each message carries the event name and is signed with a secret, using an HMAC-SHA256 signature in a header, so the receiver can check it is genuine.
- Failed deliveries are retried automatically, with growing gaps between attempts, before being marked as failed.
- A test event can be sent to confirm the endpoint works.
Which events are available depends on your integration. Talk to the myKutir team about what you need before building anything.
Testing webhook functionality
- Ask for a test event to be sent to your endpoint.
- Check that your system received it.
- Verify the signature using the shared secret.
- Check that your system responds quickly with a success code.
- Confirm that a temporary failure on your side is retried.
Common pitfalls and how to avoid them
- Not checking signatures: anyone could send fake messages to an open URL.
- Slow receivers: respond quickly, then process the message in the background.
- Handling the same message twice: retries can repeat a message, so make processing safe to repeat.
- Sending more data than needed: keep personal data to a minimum.
Manual or automated data sharing?
| Area | Manual export | Webhooks |
|---|---|---|
| Timeliness | When someone exports | When the event happens |
| Effort | Repeated by hand | Set up once |
| Security | Files emailed around | Signed messages |
Best practices for maintaining webhook endpoints
- Keep the shared secret private and rotate it if it leaks.
- Monitor failed deliveries.
- Document what each event is used for.
- Remove endpoints you no longer use.
Frequently asked questions
Do most societies need webhooks?
No. Most societies use the myKutir app and its exports, such as Tally export, directly. Webhooks are for societies connecting another system of their own.
Can a society set up its own webhook?
Webhook endpoints are set up with the myKutir team, so the events and data shared can be agreed first.
Key takeaways
- Webhooks push event messages to another system as they happen.
- myKutir signs every message and retries failed deliveries.
- Agree on events with the myKutir team before building.
- Verify signatures and keep personal data to a minimum.