The Leadfeeder API supports two ways of authenticating your requests. You can use a personal API key, or you can use OAuth 2.0.
Both give you access to the same API. They suit different situations.
API key or OAuth
An API key is tied to one person. It inherits that person's permissions, it never expires on its own, and it is passed on every request in the x-api-key header. This is the fastest way to get started, and it works well for a script, a one-off data pull, or an internal tool that only you run.
OAuth is tied to an application. You register the application once in Leadfeeder, and every user who wants to use it signs in with their own Leadfeeder account and approves the access the application is asking for. The application receives a short-lived access token instead of a permanent credential.
Use OAuth when any of the following is true:
The integration will be used by more than one person in your company.
You are building something that connects Leadfeeder to another system, such as a CRM or an internal application.
Your security team does not want long-lived credentials stored in production systems.
You want to limit exactly what the integration can read and write.
What OAuth gives you
Access that is scoped. When you register an application you choose the scopes it can use. An application with "View companies" can read company data and nothing else. It cannot touch your lists, your contacts, or your custom fields.
Tokens that expire. Access tokens are short-lived. If one leaks, the window of exposure is small. A refresh token keeps the integration running without anyone signing in again.
Access that survives people leaving. The application belongs to the company, not to a single user's key. You are not left rotating a personal credential when someone changes role.
Consent the user can see. Before an application gets access, the person authorizing it sees the application name, its logo, and the list of permissions it is asking for.
What stays the same
OAuth does not replace API keys. Existing API key integrations keep working exactly as they do today, and you can run both side by side.
OAuth also does not grant more access than the person authorizing it already has. Every request is checked twice. The token needs the right scope, and the signed-in user needs the matching permission in the platform. If either is missing, the request is rejected.
What is not supported yet
Public applications. Only internal applications are available in this release. Public applications, for third-party developers publishing to a marketplace, are coming later.
Client Credentials. Leadfeeder supports the Authorization Code grant only. The API works at the level of an individual user, so every call is made on behalf of a signed-in person.
Next steps
--
Questions, comments, feedback? Please let us know by contacting our support team via the chat or by sending us an email at support@leadfeeder