Get access to the API
Customers and partners request credentials for each application that will interact with MyCRM. Keep these credentials safe: treat them with the same care as your MyCRM password. Share them only with authorised people who need them to configure your integration, and keep secrets out of public pages, shared repositories and logs.
Contact Ask LMG through your usual MyCRM support channel with:
- The business outcome and operations required, such as reading contacts or creating leads.
- The organisation or subscription context for data access.
- Whether the application needs to read, search, create, update or delete information.
- Whether it needs webhook notifications, and which changes it should receive.
- The intended environment and whether any requested endpoints are in beta.
LMG may need additional information before issuing credentials. You will receive the application credentials, service URLs, available scopes and adviser context appropriate to your integration.
Leads-only access
For creating leads, credentials can be self-served within MyCRM under Profile Management → API Access Management. If the page is unavailable to you, ask the head adviser or business owner to assist.
Why MyCRM uses OAuth 2.0
Before an application can use MyCRM’s API, it needs a way to prove who it is and what it is allowed to do. OAuth 2.0 provides a standard process for that access. Your integration exchanges its application credentials for an access token, then uses that token when calling the API.
For a business owner, the key idea is that the connection has its own approved access. You do not give the integration an adviser’s MyCRM password.
How the connection works
Think of the token as a temporary access pass:
- LMG approves access for your application. You receive a client ID, a client secret and the details of the environment it can connect to.
- Your application requests a pass. It authenticates with those credentials and requests the approved capabilities it needs, called scopes.
- MyCRM issues an access token. The token has a limited lifetime. Your application presents it with its API requests.
- The application obtains another token before expiry. This happens in the background; someone does not need to sign in each time.
MyCRM uses OAuth’s client credentials flow, designed for applications that can keep credentials securely on a server. There is no user sign-in screen or browser approval redirect in this flow. The OAuth 2.0 standard describes the exchange.
Why use OAuth instead of an API key?
A simple API-key integration often sends the same long-lived secret with every request. MyCRM separates the application’s long-lived credentials from the temporary credential used to access data.
| Benefit | What it means for your integration |
|---|---|
| Time-limited API access | Access tokens expire, limiting how long a leaked token can be used. The application uses the returned expiry time when obtaining its next token. |
| Explicit capabilities | Scopes describe what the application can request, such as reading contacts or creating leads. It cannot grant itself access simply by asking for more scopes. |
| Separate credential handling | The client secret is used with the authentication service; API requests carry the token. This reduces where the long-lived secret needs to be sent. |
| A standard connection process | Developers can use established OAuth libraries and tooling rather than implement a custom authentication scheme. |
API keys can also be designed with restrictions, expiry and rotation. OAuth gives MyCRM a standard framework for combining these access controls; it does not remove the need to protect credentials.
Both the client secret and access token must stay private. Anyone holding a usable bearer token can present it to the API, so keep tokens out of public pages, shared files and logs, and use HTTPS. These protections are part of the OAuth bearer-token guidance.
What access means
An application's scopes control the operations it may perform. Its organisation or subscription context controls the records it may access. The UserId header identifies the adviser context; it does not expand the access granted to the application.
The technical OAuth guide covers token requests, reuse and expiry. With client credentials, request another access token when needed; do not assume a refresh token will be issued.
See scopes and data visibility, then make your first request.