Send UK planning applications to Reapit
Raise an enquiry in Reapit the moment an application appears on a patch one of your branches covers.
Reapit runs on Foundations, its API platform, which registers developers directly and gives them a sandbox that accepts writes as well as reads. Plota brings UK planning applications from 389 council planning portals into one classified, source-linked feed. Point it at Foundations and the negotiator who covers a street learns about a scheme on it the day the council publishes the application, with the address, the description and the official council link already attached.
Before you start
- Get an API key (a free demo key works for testing).
- Create a saved alert in Plota for the area and categories you want, and note its alert id.
How to connect Plota to Reapit
Save an alert that matches a branch patch
In Plota, create a saved alert for the councils, wards or postcode sectors one branch covers, and the categories that branch cares about. Note the alert id. Agencies usually run one alert per branch rather than one for the business, because the routing is the point.
Get Foundations credentials
Foundations is OAuth 2.0 and OpenID Connect, with authorisation code or client credentials, and no API-key option. Tokens come from https://connect.reapit.cloud/token and calls go to https://platform.reapit.cloud with an api-version header, currently 2020-01-31. Client-credentials calls also carry reapit-customer, which is the customer id, or SBOX against the sandbox. Register through the Reapit developer portal; the sandbox processes read and write requests, so the whole flow can be proved before an agency is involved.
Send Plota to an endpoint you control
Foundations webhooks run outbound only: they tell your system when something changed inside Reapit, and there is nothing on the Reapit side that receives an inbound call. So Plota delivers to your own endpoint or automation platform, and that code calls Foundations. Register the Plota side in your dashboard under Webhooks → Add a webhook, or via the API:
curl "https://api.plota.co.uk/v1/webhooks" \
-H "Authorization: Bearer plota_live_your_key" \
-H "Content-Type: application/json" \
-d '{"url": "https://your-service.example.com/plota/reapit", "alert_id": 123}'Create the enquiry
POST /enquiries/ is the right landing place, because an enquiry is already the object a branch triages. It requires title, forename, surname, enquiryType, message, officeId, marketingConsent and sourceName. The enquiry types include salesProperty and lettingsProperty for a prospective vendor or landlord, which matters here: Foundations has no create endpoint for a vendor, so a prospective-vendor lead enters as an enquiry. Reapit’s own example for this endpoint uses a portal name in sourceName, which is exactly the shape of a Plota match.
Carry the planning reference in Metadata
Foundations calls custom data Metadata, and most create and update endpoints accept a metadata object. Two do not, and they are the two lead-shaped ones: /enquiries/ and /journalEntries/. So put the planning reference on the contact or property the enquiry produces, or write a standalone POST /metadata/ record with your own entityId. Metadata is searchable afterwards with ?metadata=metadata.<field> $eq '<value>', which is what makes a redelivery safe.
Two Foundations details worth knowing before you design this
There is no POST /vendors/: vendor records can be read and updated but not created, which is why a prospective-vendor lead goes in as an enquiry with enquiryType set to salesProperty. And resource ids are unique per customer rather than globally, so anything you store on your side should be keyed on the customer id and the resource id together.
Field mapping
What arrives from Plota, and where it belongs in Reapit. Plota field names are the ones in the API reference; every webhook carries them under data.application.
| Plota | Reapit | Notes |
|---|---|---|
description | Enquiry message | What the applicant has applied for, in the council’s words |
address | Address line1 to line4, with buildingName and buildingNumber | Enquiry and property addresses share this shape |
postcode | Address postcode | Country is countryId, an ISO-3166 code |
location.lat, location.lng | address.geolocation.latitude and .longitude | Property addresses only. Enquiry and contact addresses have no geolocation field |
reference | A metadata field on the contact, property or task | Not on the enquiry: /enquiries/ does not accept metadata |
links.plota, links.council | Enquiry message, or a journal entry description | Keeps the council’s own record one click away |
(the feed itself) | Enquiry sourceName | Reapit’s documented example puts a portal name here |
What teams use this for
The patch a negotiator actually covers
One alert per branch, filtered to that branch’s councils and wards. The enquiry lands with the address and postcode on it, so it routes to the right person without anyone reading a council list.
Owners who are already spending
Householder extensions, loft conversions and garage conversions carry the address and a description of the work. An agent can see the scheme before they call rather than after a competitor has.
Land and new homes
Filter to new homes and major works. Plota states a dwelling count where the council’s own description gives one, so a scheme of 10 or more homes is separated at the alert rather than by hand afterwards.
Verify deliveries
Each webhook is signed - verify the Plota-Signature header (HMAC-SHA256 over timestamp.body). Full details in the API docs.
Reapit integration FAQ
Can I send UK planning applications into Reapit?
Yes. Plota fires a signed webhook when an application matches your saved alert, your own endpoint or automation platform receives it, and it creates the record through the Reapit Foundations API. Foundations documents create endpoints for enquiries, contacts, applicants, landlords, properties, tasks and journal entries among others.
Does Reapit accept a webhook from Plota directly?
No. Reapit’s webhooks are outbound: they notify your system about changes inside Reapit. Something you control has to sit between Plota and Foundations, whether that is a few lines of code, a Zapier or Make scenario, or an n8n workflow.
Can I create a vendor record from a planning application?
Not directly. Foundations has no create endpoint for vendors. The documented route for a prospective-vendor lead is POST /enquiries/ with enquiryType set to salesProperty, which is how portal leads arrive too.
Where does the planning reference live?
In Metadata, Reapit’s mechanism for custom data. Note that /enquiries/ and /journalEntries/ do not accept a metadata object, so store it on the contact or property, or as a standalone metadata record with your own entity id. It can then be queried back, which is how you keep a retry from creating a second enquiry.
Do I need a Reapit developer account?
Yes, to get credentials. Reapit registers developers through its own portal and runs an AppMarket, where an app can be listed publicly or privately. The sandbox supports read and write requests, so you can build and test before an agency installs anything.
Is there a Reapit app on Zapier?
Not that we can find. Reapit’s route is its own API. For a no-code path, run the Plota webhook into Zapier, Make or n8n and have that call Foundations over HTTP.
Is it free?
You can test Plota with a free demo key. Live webhook delivery runs on the Starter plan and above. Plota’s public planning search and email alerts stay free. Reapit sets its own developer and partner terms.