Guides

Bringing in leads from portals and your own website

Last updated 2026-09-14

A buyer who fills in a form on a listing portal is not waiting by their email. They enquired about four projects the same evening, and they will talk to whichever seller replies first.

Anything that already collects leads for you — MagicBricks, 99acres, Housing.com, NoBroker, IndiaMART, JustDial, a channel partner, or your own website — can push them into Vesma as they arrive, and the assistant answers in seconds like any other enquiry.

Why a portal lead goes cold fastest

Portal enquiries are the ones most often answered late, because they arrive into an inbox rather than into a conversation. By the time someone exports the sheet and starts calling, the buyer has already spoken to somebody else.

Nothing about this needs approval from Meta, Google or anyone else. It is available on every plan, including the free one.

Creating a key

Go to Settings › Leads from portals. Give the key a name you will recognise later (“MagicBricks feed”), choose which source leads arriving on it came from, and create it.

The key is shown once. Copy it then — it is stored hashed and cannot be shown again. If you lose it, turn that key off and make another; nothing else breaks. Only a workspace admin can create or turn off keys.

Use a separate key per feed. That way turning one off stops that feed and nothing else.

What to send whoever owns the feed

One HTTP request, with a name and a phone number as the minimum. The screen gives you a ready-made block of instructions you can copy or email straight to a portal contact or a developer:

Method and address. A POST to the lead ingest endpoint, given in full on the screen.
One header. The API key you just created.
A JSON body. Name and phone are required; email and the enquiry text are worth sending if the portal has them.

Once it is live, the key records when it was last used — so a feed that has quietly stopped working is visible rather than being mistaken for a slow week.

You probably do not need to reshape anything

Portals all spell their fields differently, and the usual sticking point is being asked to rewrite an export that already works. Common spellings are read automatically — SENDER_NAME, SENDER_MOBILE, mobile, fullName and others — so an existing feed usually works unchanged.

The enquiry text is worth sending even when it is messy. Free text like “3BHK in Whitefield” is read into configuration and location, which means the lead arrives partly qualified and scores higher from the first moment.

Why the key decides the source, not the payload

Each key is bound to one source, and that is what the lead is recorded as. A source named inside the payload is ignored.

This is the whole reason keys exist rather than an open endpoint. Anyone can post to a public enquiry form and claim to be MagicBricks; a keyed caller has proved which integration it is. It is what makes “where did our business actually come from” a question your reports can answer honestly.

What this does not do

It does not log in to a portal or scrape one for you. The portal, or your developer, sends the lead to us. There is no credential to hand over and nothing pretending to be you.
It cannot read anything out of your workspace. An ingest key only writes leads in. It cannot list your leads, read conversations, or change anything.
It does not deduplicate across feeds. The same buyer enquiring on two portals arrives as the lead each portal sent.
One thing to get right

Treat the key as a password. Anyone holding it can create leads in your workspace. Send it to the person who needs it, not to a group chat, and turn it off the moment a supplier relationship ends.

Answer portal leads before your competitor does

One key, one request, and every enquiry from your portals is answered in seconds instead of after the export.