Skip to main content
The Lead Intake API is how a partner, a landing page or an ad platform puts an enquiry into Provident’s CRM. A lead posted here is indistinguishable from one typed in by an agent: it is deduplicated against our contacts, routed to an agent by our assignment engine, and starts the same follow-up clocks.

Read the handbook

The complete integration guide — authentication, every field, matching behaviour, webhooks and the go-live checklist.

Browse the endpoints

Generated from our OpenAPI spec, with a request builder you can call from the page.

​
The shape of an integration

1

Get credentials

Ask Provident for a client id and secret. There is no self-service signup.
2

Exchange them for a token

OAuth 2.0 Client Credentials against POST /v2/oauth2/token. No user login, no redirect, no consent screen — your server talks to ours.
3

Post the lead

POST /v2/public/leads with the customer’s name and at least one way to reach them. Everything else is optional and improves routing.
4

Find out where it landed

Either take the webhooks and be told, or poll GET /v2/public/leads/{id}/assignment. Prefer the webhooks.

​
Environments

Build against staging first. Credentials are issued per environment — a production secret will not authenticate against dev, and vice versa.

​
Two things worth knowing up front

Most optional fields are matched against our own catalogues — sources, campaigns, developers, locations. When a value matches nothing we keep it verbatim and return it under intakeUnresolved rather than failing the request. A lead is never lost over a field we could not match.
Routing runs after we answer your POST, so assignedTo can legitimately be absent at create time. GET /v2/public/leads/{id}/assignment distinguishes “routing hasn’t finished” from “nobody took it” — read it before treating an ownerless lead as an error.

​
Support

Integration questions go to it@provident.ae. Include the lead id from the response — it is the fastest way for us to trace what happened.