Before your integration can ask a Leadferno admin to connect, it needs an OAuth client (client_id + client_secret) registered against a redirect URI.
Option A — we register it for you
Send us:
Your OAuth redirect URI — the HTTPS URL we return the authorization code to. We match it literally, character for character.
Your webhook endpoint — the HTTPS URL where we POST event payloads.
We return:
client_idclient_secretThe redirect URI(s) on file — verify them exactly
Enabled grant types — always
authorization_codeandrefresh_token
Option B — create it via the API
An admin access token can create the account's OAuth client directly:
JSONPOST /v0/customers/{customer_uuid}/oauth/credentials
Authorization: Bearer <admin_access_token>
Content-Type: application/json
{
"name": "Acme CRM Sync",
"redirect_uris": ["https://yourapp.example.com/leadferno/callback"]
}Response (201):
JSON{
"name": "Acme CRM Sync",
"client_id": "...",
"client_secret": "...",
"redirect_uris": ["https://yourapp.example.com/leadferno/callback"]
}redirect_urisis an array — register every callback URL you use, here.Grant types are fixed to
authorization_code+refresh_token.The
client_secretis shown once, on creation.
One OAuth client per Leadferno account. Creating credentials again replaces the existing client and invalidates every token issued under the old one. If you need separate staging and production clients, use separate Leadferno accounts or ask us to manage a second client.
Before you go live
The redirect URI must be reachable over HTTPS to complete a test sign-in.
The webhook endpoint must return
2xx. An endpoint that returns410will be auto-unsubscribed (see Subscribe to webhook events).
Protecting the client secret
Store it server-side only — never in browser code, a mobile app, a public repo, or a client-side config file.
If it's ever exposed, tell us (Option A) or re-create the credentials (Option B) to rotate it. A leaked secret plus your redirect URI is most of what someone needs to phish an admin's authorization.