Build and Test CRM Integrations Without Touching Live Data

The developer platform is one area inside your HelloGrowthCRM account where everything needed to build on the CRM lives together: the credentials your code uses, practice workspaces to run it against, the reference that describes each endpoint, the webhooks that tell your systems when something changes, and a log that shows every call from our side. The REST API behind it covers leads, deals, tasks and notes.

It exists for a simple reason. Most integration problems are not caused by hard code. They are caused by testing against real customer data, by credentials that can do more than they need to, and by failures nobody can see. Each part of the platform removes one of those. An administrator switches the area on by enabling Integrations for the workspace; until then, the API and sandboxes are not available to it.

There are two ways for code to act on HelloGrowthCRM, and choosing the right one first saves a rebuild later.

API keys, for your own workspace

An API key is for an integration that serves your own business: your website sending leads in, your ERP reading won deals, a script that tidies records at night. When you create a key you name it, say what will use it, and tick exactly what it may do. A key that only needs to read leads should not be able to delete deals, and here it cannot. The secret is shown once. Only a fingerprint of it is stored, so if it is lost you create another rather than recover it, and revoking a key stops everything using it immediately.

Apps, for software other companies connect

An app is for software that many companies will connect to their own HelloGrowthCRM workspace, such as a product you sell or a service you run for clients. Apps use OAuth 2.0 with PKCE. You get a client id, which is public and safe to share, and a client secret, which is shown once and can be rotated. Each customer sees your app’s name on a consent screen and grants the access it asks for, or less. A company can always narrow what an app may do; it can never be made to grant more than the app requested.

A sandbox is a separate practice workspace that you create in the developer area. It arrives seeded with sample leads and deals, so your first request has something to read. The sample data is synthetic: invented company names and reserved phone numbers, never a real person.

Sandboxes pair with test keys. A test key belongs to one sandbox and the database refuses it anywhere else. That rule is enforced by the database itself, not by a setting someone could change, so a mistake in your code, a copied config file or a wrong environment variable cannot turn a test into a change to real customer records. Every response also tells you whether it reached test or live data, and which sandbox, which is the quickest check when a result looks wrong.

When a sandbox gets messy, reset it. Everything in it is deleted, including the leads, deals and tasks you created through the API, and the sample data is put back. Your keys are left alone, so the same code runs again against a clean starting point. Webhooks are split the same way, into sandbox endpoints and live endpoints, each with its own delivery history.

The API reference lists every endpoint, parameter and response, and it is rendered from the schema the running API publishes about itself rather than written by hand. That matters more than it sounds: documentation that is typed separately drifts, and a developer who trusts a stale page loses an afternoon. Here the reference can only describe what is actually deployed.

The console is where you send requests without writing any code. It offers exactly the endpoints the API publishes, prefills the fields each one requires, and shows the full request and response. Paste a test key and you are working on your sandbox. Paste a live key and the console tells you plainly that the call changes real data, and asks you to confirm before it sends. The key you paste is kept in the browser tab only and is never saved; the copyable version of the request shows a placeholder instead.

Code samples are available in cURL, Node.js, Python, Java, PHP and Go. Each one sends only the fields an endpoint requires, so it is the smallest call that works and a clean base to build from. Documentation pages can also be copied as Markdown or opened directly in Claude, ChatGPT, Cursor or Perplexity, which is useful when a developer works with a coding assistant and wants it reading the real reference rather than guessing at field names.

The documentation starts with a short overview of what you can build and the three things you need to begin: a sandbox, a credential, and an endpoint to call. A single search box looks across the developer area’s screens, documentation and endpoints at once, so finding the webhook settings or the reference for one endpoint does not mean remembering which tab it is on.

Polling asks the CRM, again and again, whether anything happened. Webhooks turn that around: you register an endpoint, choose the events you care about, and the CRM sends each one when it happens. The list you choose from only includes events the product actually sends, so anything you subscribe to will arrive.

Endpoints must use https and be reachable from the internet; while building, a tunnel to your own machine works fine. Every delivery carries a signature made with a signing secret you issue for that endpoint, so your server can verify that a message really came from HelloGrowthCRM before acting on it. Secrets can be rotated; from that moment every delivery is signed with the new one, so update your verification first. For apps, one endpoint receives events from every connected workspace, including ones that connect later, so you never register anything per customer.

Each endpoint has a delivery history. It shows what was sent, the status your server returned, and deliveries your server never answered because the request was refused, timed out or could not reach the address. You can narrow it to failures only, which is usually the list you want.

When a call fails, the hardest question is usually where. The request log answers it. It lists every call your API keys made, with the reason for each failure, and apps have their own log of the calls they made on behalf of connected workspaces.

Every response carries a request id. Paste it into the log and you see that exact call from our side. It is also the id to quote if you ask us about a response, so a support conversation starts from a fact rather than a description. Together with the mode and sandbox shown on each response, it removes most of the guesswork from debugging an integration.

Every app starts in test. A test app gets a client id and secret for the sandbox, and it can never reach a real workspace, so you can build the whole connection flow, including the consent screen and token exchange, without any customer involved.

The flow is standard OAuth. You send a customer to your app’s authorise link. They choose their workspace, approve the access on the consent screen, and return to your redirect address with a code. Your server exchanges that code for tokens and calls the API with the access token, refreshing it when it expires. The exchange needs your client secret, so it always happens on your server and never in the browser. Redirect addresses must use https, with plain http allowed only for localhost while you develop.

When the app works, create its live version. Your own workspace can connect the live version straight away, which is the same reach as a live API key an administrator could already create. Other companies can connect it once HelloGrowthCRM has reviewed it. A list of installs shows which workspaces are connected, identified by an install id rather than company details, and an install disappears from the list the moment that workspace disconnects.

1. Ask an administrator to enable Integrations for your workspace.
2. Create a sandbox. It arrives with sample leads and deals.
3. Create a test key for that sandbox and tick only what it needs to do.
4. Send your first request from the console, or copy the sample in your language and run it.
5. Register a sandbox webhook endpoint and create a lead to see the event arrive.
6. Check the request log and the delivery history for anything that failed.
7. When it works, create a live key, or the live version of your app, and point the same code at your real workspace.

Before going live, decide which system owns each field that exists in both, and keep assignment, sequences and reminders inside the CRM rather than rebuilding them in your integration. Those two decisions prevent most of the problems that appear months later.

The developer platform is for teams with a developer or an implementation partner. If you do not have one, start with our Zapier integration or a native connector from the integrations catalogue, and read API vs Zapier to see where each route fits.

For the business case behind connecting systems, see API and webhooks. The public API guide documents the REST resources and field rules that our Zapier and Make connections use. The HelloGrowthCRM MCP server is a different thing again: a public, read-only service that answers AI assistants’ questions about the product, not a connection to your CRM data. Access your own records from code through the API and credentials described here, and review role permissions and audit logs for how access is controlled and recorded inside the CRM itself.

Continue with all features, data import, security, and pricing.

See also: API and Webhooks · Custom Fields · Data Export · API vs Zapier