Salesforce to GoHighLevel migration requires careful object mapping, API rate limit management, and a dependency-ordered ETL pipeline — CSV imports silently destroy relational data at scale.
Salesforce to GoHighLevel migration has no native migration path and requires significant custom mapping work due to fundamental data model differences. Salesforce uses a deeply relational schema with Accounts, Contacts, Leads, and Opportunities linked through lookup and master-detail relationships, while GoHighLevel is contact-centric with a flat data model where everything radiates from the Contact record. Custom work is required to flatten relational hierarchies, merge Salesforce Leads into GHL Contacts (since GHL has no separate Lead object), pre-compute formula fields, and architect around GoHighLevel's hard limit of 10 Custom Objects per location. Preserving referential integrity demands ETL-layer transformations, user crosswalk tables, and concatenated key strategies that go well beyond simple CSV exports.
Read this first
Pair-specific gotchas that catch teams out. Each one has cost somebody a weekend.
Freeze schema changes while mapping
New custom fields, picklist values, workflows, or routing rules introduced mid-project are a common reason test results do not match production cutover results.
Older advice that says GoHighLevel has no real custom objects is outdated
Current docs show Custom Objects on all plans with API support, workflow support, associations, and CSV import. The real constraints are the 10-object cap, limited unique field types, and support gaps across some product surfaces — including Email Campaigns, Bulk Email/SMS, Conversations, Calendars, and Payments. (help.gohighlevel.com)
Zapier is a sync tool, not a migration engine
HighLevel's official Zapier connection uses the LeadConnector app and authenticates to a specific sub-account. That works for narrow live automation. It is a bad fit for replaying years of Salesforce history with cross-object reconciliation.
Salesforce API limits operate on a rolling 24-hour window, not a fixed calendar day
If you exhaust your quota at 3 PM, it won't reset at midnight — it resets at 3 PM the next day. Plan extraction runs accordingly.
GoHighLevel rate limits are scoped per Marketplace app per Location
If you're migrating multiple sub-accounts, each sub-account gets its own 200K daily quota. For single-account migrations, you have one pool of 200K requests to work with.
Build an ID mapping table
For every Salesforce record loaded into GHL, store a mapping of {salesforceId: ghlId}. You need this to rebuild relationships (e.g., linking an Opportunity to its Contact) and for post-migration validation.
If you use GoHighLevel webhooks for delta sync, verify X-GHL-Signature on incoming payloads
GHL only retries webhook deliveries on 429 responses, not on 5xx errors. (help.gohighlevel.com)
The runbook
Work top to bottom. Tick steps as you go — your progress is saved in this browser.
01 Discovery Agree scope, pipeline design and success criteria before touching data.
Objective A scope covering every object in the revenue model, with sales leadership signed up to the pipeline design.
Keep these open
-
Inventory every object in Salesforce
Count accounts, contacts, leads, deals or opportunities, activities, notes, emails, files, products and quotes. Activity and email history is usually the largest object by an order of magnitude and the one people forget to size.
Data Profiler Get real record counts instead of estimating from memory -
Map the current pipeline and agree the target model
Document every pipeline, stage, probability and required field, then agree the HighLevel model with sales leadership. Migrating a broken pipeline faithfully is a wasted opportunity; redesigning it mid-migration is a wasted migration.
Stage changes alter historical conversion rates. Agree how you will restate reporting before you change the model.
-
Catalogue integrations and automation
List every system touching Salesforce: marketing automation, quoting, billing, ERP, data enrichment, dialler, BI. Each is a separate cutover task with its own owner, and each can silently write bad data into your new CRM.
-
Capture the reporting that must survive
Interview the people who actually live in the dashboards — forecast, pipeline coverage, rep activity, cohort conversion. Every one of these needs the underlying fields to migrate, which frequently expands the scope.
-
Build the business case and pick the go-live date
Model licence delta, implementation effort and productivity dip. Then choose the date deliberately: mid-quarter is disruptive, quarter-end is worse. Most teams land on the first week of a new quarter.
COI & ROI Calculator Build the 36-month business case you will need for sign-off -
Define migration scope
Not everything needs to migrate. Determine the cut-off date for historical data (e.g., only closed-won opportunities from the last 3 years). Decide what's operationally active, what can be archived, and what's disposable.
-
Create GHL target metadata
Set up Pipelines, stages, Custom Fields, and Custom Objects in GoHighLevel before importing any data. If your CSV file includes data for fields that do not yet exist in HighLevel, you will need to create those fields as Custom Fields before completing the import. HighLevel allows you to map CSV columns to both standard and custom fields, but only if those fields are already created in your account.
Salesforce → HighLevel specifics
- Cost consolidation
- Salesforce Enterprise Edition licensing adds up fast — per-user costs, add-on fees for CPQ, Marketing Cloud, and Pardot. GoHighLevel bundles CRM, pipeline management, marketing automation, funnels, SMS/email, and appointment scheduling into a single subscription.
- Operational simplicity
- Salesforce's power is its configurability, but that configurability creates admin overhead. Teams running fewer than ~50 users often don't need Flows, Process Builder, validation rules, and multi-tier permission sets. GoHighLevel's workflow builder covers 80% of those use cases with less setup.
- Agency model fit
- GoHighLevel was built with agencies in mind. Its sub-account architecture, white-label options, and SaaS mode let agencies resell a branded CRM to clients — something Salesforce doesn't natively support without significant custom development.
- Purge dead data
- Delete or archive inactive records, unused custom objects, and orphaned lookup references before export. Do not migrate garbage into a fresh system.
- Big bang
- Full load, short freeze, final delta, cutover. Simpler but higher risk.
Don't move on until
- Object counts confirmed for accounts, contacts, deals and activities
- Target pipeline and stage model agreed with sales leadership
- Reporting requirements captured from the people who use the reports
02 Data Audit CRM data is usually dirtier than anyone expects. Find out how dirty.
Objective A profiled export with duplicates, ownership gaps and relationship integrity all quantified and triaged.
Keep these open
-
Export and profile every object
Profile null rates, distinct values and type consistency across all objects. Pay attention to fields sales reps were supposed to fill in: an 80% null rate on a field your forecast depends on is a business finding, not a data one.
Data Profiler Profile the Salesforce export for nulls, outliers and type drift -
Quantify duplicates and agree the merge policy
Measure duplicate accounts (same company, different spellings and suffixes) and contacts (same email, or same person at a renamed company). Agree survivorship rules before merging: which record wins, which fields, and what happens to the activity history on the loser.
Merging before you have agreed survivorship rules destroys history irreversibly. Decide first, merge second.
Data Cleaner Strip empty rows, stray whitespace and dead columns -
Verify relationship integrity
Check every deal has a valid account, every contact a valid account, every activity a valid parent. Referential breaks are the defect that turns a clean-looking load into a CRM where the pipeline report does not tie to the account list.
-
Resolve ownership and the user map
Build the Salesforce user → HighLevel user map, including leavers. Every record needs a valid owner: records assigned to deactivated users either fail to load or land unassigned, and unassigned pipeline is pipeline nobody works.
Records owned by deactivated users are a top cause of load failures. Decide the reassignment target before you start.
-
Scan for PII and regional compliance
CRMs hold marketing consent, lawful basis and unsubscribe state. Confirm these fields migrate intact and that consent provenance survives — losing consent records is a regulatory problem, not a data-quality one.
PII & Compliance Scanner Find regulated fields before they land in a new system -
Clean, normalise and archive the pre-state
Normalise country and state values, phone formats, currencies and casing, and standardise all timestamps to UTC. Keep an untouched copy of the raw export — it is your only reference if a mapping decision turns out wrong.
Salesforce → HighLevel specifics
- Data audit
- Run record counts for all Salesforce objects in scope: Accounts, Contacts, Leads, Opportunities, Activities, Custom Objects. Include owners, queues, assignment rules, and integrations that read or write Salesforce.
- Zendesk Extraction
- Use Zendesk's Incremental Export API with cursor-based pagination. The standard Ticket API limits you to 100 pages, but the Incremental API can extract millions of records reliably.
- Salesforce Loading
- Use Salesforce Bulk API 2.0. Insert Accounts, then Contacts, then Cases, then EmailMessages.
- Rate Limits
- Zendesk allows 400–700 requests per minute depending on your plan. Salesforce Bulk API 2.0 handles up to 150 million records per 24-hour rolling window.
Don't move on until
- Duplicate rate quantified per object with a merge policy agreed
- Every record has a valid owner mapped to a target user
- Relationship integrity verified — no orphaned deals or contacts
03 Field Mapping Map objects, relationships and picklists — in that order.
Objective A signed mapping spec that covers objects, relationships, picklist values and currency handling.
Keep these open
-
Map objects and their relationships first
Establish how Salesforce objects correspond to HighLevel objects before any field work. Leads-versus-contacts, accounts-versus-organisations and deal hierarchies differ structurally between CRMs, and a field map built on the wrong object model has to be redone.
Schema Mapper Opens pre-loaded with the Salesforce → HighLevel field pair -
Generate and then hand-review the field map
Auto-match both schemas, then review every row. Look hardest at anything named "type", "source", "stage" or "status", where names match and meanings do not.
-
Map every picklist value, including retired ones
Enumerate all values on both sides — deal stages, lead sources, industries, statuses — and map each explicitly, including values no longer offered but still present on old records. Unmapped values either fail the row or land as blanks that quietly break segmentation.
Historical records often carry picklist values that were retired years ago and no longer appear in the UI.
-
Decide currency, amount and date handling
If you sell in multiple currencies, confirm how HighLevel stores amounts, exchange rates and dated conversion rates. Recalculating historical deal values at today's rate silently rewrites your revenue history.
Multi-currency deals re-converted at current rates will not tie to your historical reporting or your finance system.
-
Determine the load order
Sequence the load so parents exist before children: users, then accounts, then contacts, then deals, then activities and notes. Keep source IDs in custom fields so relationships can be rebuilt by lookup rather than guesswork.
-
Freeze the spec and sign off
Version-control the mapping, walk RevOps and sales leadership through the decisions that change reporting, and get written sign-off before the pilot.
-
Merge Salesforce Leads and Contacts
into a single GHL Contact dataset. Add a lifecycle_stage custom field to distinguish them.
-
Map Salesforce picklist values
to GHL dropdown option IDs (or create matching options first via API).
-
Map Opportunity stages
to GHL Pipeline stage IDs. Create the Pipeline and stages in GHL first, capture the IDs, then reference them in the transform.
Data Format Converter Reshape the export into the format HighLevel's importer expects
Salesforce → HighLevel specifics
- Pre-compute formula fields
- Salesforce formula fields export as the computed value at export time, not the formula. Decide which to keep as static values.
Don't move on until
- Object and relationship model mapped and reviewed
- Every picklist value explicitly mapped, including dead values
- Load order determined so parents always exist before children
04 Test Migration Pilot with related records, not a flat sample.
Objective A pilot load whose relationships, ownership and roll-up reporting all verify against source.
Keep these open
-
Configure the HighLevel sandbox to match the agreed model
Build the pipelines, stages, custom fields, record types and user roles first. Load into a default configuration and you will only discover the configuration defects at full scale.
-
Select a connected pilot slice
Take complete account trees — 50-100 accounts with all their contacts, deals, activities and files — rather than a flat random sample. Relationship defects are the whole point of a CRM pilot and a flat sample cannot expose them.
-
Run the load in dependency order with full logging
Load users, accounts, contacts, deals, then activities, logging every request against its source ID. Note which failures are transient (rate limits, timeouts) and which are structural (validation, missing parent).
-
Verify relationships and roll-ups
Confirm every deal sits on the right account with the right owner and stage, and that pipeline totals per account and per rep match Salesforce exactly. Roll-up mismatches almost always mean a relationship or currency defect upstream.
Migration Validation Tool Diff the pilot batch against source before scaling up -
Measure throughput and project the full load
Record actual records-per-hour under HighLevel's API limits and extrapolate, remembering activity history usually dominates volume. If the projection exceeds your window, split the load or trim activity scope now.
-
Let reps work the pilot data
Put two or three reps in the sandbox against their own accounts. They spot missing context, wrong owners and unusable notes far faster than any reconciliation script, and their buy-in is what makes adoption work.
Salesforce → HighLevel specifics
- Data Fidelity
- Compare record counts. Are there exactly as many Closed Cases in Salesforce as Solved/Closed Tickets in Zendesk?
- Relationship Integrity
- Pick 50 random Cases. Do they link to the correct Contact and Account?
- Routing Tests
- Submit a test case via Email-to-Case. Does the Assignment Rule route it to the correct Queue?
- Agent UAT
- Have 3–5 agents log into the Salesforce Full Copy Sandbox. Ask them to find a historical case, reply using a Macro, and close it.
Don't move on until
- Relationships intact across the whole pilot slice
- Pipeline roll-ups match source for the pilot accounts
- Reps have worked pilot records and confirmed they are usable
05 Cutover Switch the revenue system with the pipeline intact.
Objective All in-scope CRM data live in HighLevel, integrations repointed, and reps selling on day one.
Keep these open
-
Pre-load history ahead of the freeze
Load closed deals, historical activities and inactive accounts while Salesforce stays live. Only open pipeline and the final delta need to move inside the window.
-
Publish the cutover runbook
A timed sequence with owners and abort criteria: freeze, final export, delta load, integration switch, smoke test, go/no-go, rep enablement. Pick a window that avoids quarter-end and month-end close.
-
Freeze Salesforce and take the final delta
Set Salesforce read-only and export everything changed since the pre-load. Reps updating deals during an unenforced freeze is the classic way to lose the most recent — and most valuable — pipeline changes.
A rep who updates a deal in the old CRM during the freeze will lose that update permanently.
-
Load the delta and reconcile the pipeline
Run the delta, then verify open pipeline value and count per rep against Salesforce before anything else. If the pipeline number is wrong on day one, reps stop trusting the system and never fully come back.
Migration Validation Tool Confirm the final delta landed before you reopen -
Repoint every integration and verify with real records
Switch marketing automation, quoting, billing, enrichment, dialler and BI connections, then push a live record through each path. An unrepointed integration writing into the old CRM causes divergence that gets harder to reconcile every day.
Two-way integrations left pointing at the old CRM will keep writing there. Disable them before you switch, not after.
Cron Expression Builder Schedule the delta syncs that run through the freeze -
Go/no-go, then enable the reps
Call the decision explicitly against the exit criteria. Run enablement on real data with their own accounts on screen, and keep Salesforce read-only rather than cancelled until validation closes.
-
Set a configuration freeze
on Salesforce. No new fields, objects, or automations during the migration build.
-
Define rollback criteria
Document what constitutes a failed migration and how you'd recover.
-
Freeze Zendesk
Change Zendesk triggers to prevent new ticket creation, or redirect your support email forwarding rules to Salesforce Email-to-Case.
Salesforce → HighLevel specifics
- Final Delta Sync
- Run the Zendesk Incremental API to catch any tickets updated in the last 24 hours.
- Rollback Strategy
- Keep Zendesk active (but read-only) for 30 days. If Salesforce routing fails catastrophically on Day 1, redirect the email forwarding back to Zendesk and use Zendesk to handle the queue while you debug Salesforce.
Don't move on until
- Historical load complete and reconciled before the freeze
- All integrations repointed and verified end to end
- Reps logged in with pipeline visible and correct
06 Validation Prove the revenue numbers tie out, then close the project.
Objective Reconciled data, forecast parity with pre-migration reporting, and signed acceptance.
Keep these open
-
Reconcile every object
Compare counts and values across accounts, contacts, deals, activities and files, plus field-level spot checks on a random sample. Produce a single report suitable for audit and for finance.
Migration Validation Tool Reconcile Salesforce and HighLevel record-for-record -
Tie the pipeline and forecast to baseline
Rebuild forecast, pipeline coverage and win-rate reporting and compare to pre-migration figures. Every variance needs an explanation — most trace back to stage or currency mapping decisions made in Field Mapping.
Stage-model changes will legitimately shift historical conversion rates. Restate the baseline rather than chasing the difference as a defect.
-
Verify ownership, visibility and permissions
Confirm every record has the right owner and that sharing rules, territories and role hierarchy give each rep exactly the visibility intended. Over-broad visibility in a CRM is a data-protection issue as much as a config one.
-
Re-profile for field completeness
Compare loaded null rates against the source profile per field. A field that arrived empty while counts matched is the failure counts alone cannot detect.
Data Profiler Prove field completeness held up through the load -
Test automation and integration write-back
Fire every workflow, assignment rule, sequence and notification, and confirm each integration writes correctly in both directions. Automation is rebuilt rather than migrated, so it is unproven until observed.
-
Sign off and schedule decommission
Get written acceptance against the Discovery criteria, keep Salesforce read-only for 30-90 days with a final archive export taken, then diarise cancellation so the contract does not auto-renew.
-
Rebuild automations
Salesforce Flows, Process Builder rules, and email alerts must be recreated as GHL Workflows. Document each Salesforce automation, map its logic to GHL's trigger/action model, and rebuild.
-
Rebuild reports
GHL's reporting is simpler. Accept that some Salesforce report complexity won't translate. Build what you can natively; export to Google Sheets or a BI tool for anything complex.
-
Run a final delta sync
Capture any records created or modified in Salesforce during the migration window.
Salesforce → HighLevel specifics
- Reconnect integrations
- Any downstream systems reading from or writing to Salesforce need to be re-pointed to GHL or replaced.
- Train users
- GHL's UI is fundamentally different from Salesforce. Schedule hands-on sessions focused on daily workflows: finding contacts, moving opportunities, logging activities.
- Don't decommission Salesforce immediately
- Keep it in read-only mode until you've confirmed everything works in GHL. Take a final backup before shutting it down.
- Tag-based routing
- Zendesk relies heavily on comma-separated tags for routing, reporting, and categorization. Dumping tags into a Salesforce text field ruins reporting. You must convert structural tags into structured fields, Record Types, and Omni-Channel assignment rules.
- Inline images and attachments
- Zendesk stores attachments as URLs within comments. Salesforce requires extracting these files and uploading them as ContentVersion records linked via ContentDocumentLink.
Don't move on until
- Full reconciliation report complete across all objects
- Forecast and pipeline reports tie to pre-migration baselines
- Acceptance signed and Salesforce decommission scheduled
Field mapping reference
The field-by-field mapping for each object. Use this as the starting point for your mapping spec.
Object GoHighLevel Equivalent
GoHighLevel's hard cap of 10 Custom Objects per location forces significant architectural compromises for Salesforce orgs with more than 10 active custom objects, requiring flattening or external archival.
| Salesforce field | HighLevel field | Notes |
|---|---|---|
| Account | Company | GHL Companies can link to Contacts, Opportunities, and Custom Objects. But the Company object has limited functionality compared to Salesforce Accounts — no direct pipeline association, limited workflow triggers. |
| Contact | Contact | 1:1 mapping. GHL's core entity. All communication, pipelines, and automations run through Contacts. |
| Lead | Contact (with tags/custom fields) | GHL has no separate Lead object. Merge Salesforce Leads into GHL Contacts and use tags or a custom field like lifecycle_stage = Lead to segment. |
| Converted Lead | Final Contact/Company/Opportunity state | Do not recreate converted leads as separate live records unless the business actively uses that history operationally. |
| Opportunity | Opportunity (inside a Pipeline) | GHL Opportunities live inside Pipelines with defined stages. Create matching Pipelines and stages before import. |
| Task / Event | Task / Note / Appointment | GHL supports Tasks on Contacts, Opportunities, Companies, and Custom Objects. Historical activities are best stored as Notes. Future-dated events with scheduling meaning map better to Appointments. |
| Custom Objects | Custom Objects (limited) | GoHighLevel supports up to 10 Custom Objects per location across all plans. Major architectural constraint — see section below. |
Zendesk objects Salesforce equivalents
| Salesforce field | HighLevel field | Notes |
|---|---|---|
| Tickets | Cases | The core object. Map Zendesk Status/Type to Case Status/Record Type. |
| Organizations | Accounts | Zendesk orgs are flat. Salesforce Accounts can be hierarchical. |
| Users (End-Users) | Contacts | Map Zendesk end-users to Contacts. Associate them with Accounts. |
| Users (Agents) | Users | Map to internal Salesforce User records. |
| Ticket Comments | EmailMessages / Case Comments | Public replies map to EmailMessage. Internal notes map to FeedItem or CaseComment. |
| Tags | Record Types / Custom Fields | Convert structural tags (e.g., escalated, tier2) into boolean or picklist fields. |
Risk matrix
Per-object risk for this pair. Plan extra validation around anything marked high.
| Object | Risk | Notes |
|---|---|---|
| Contacts | low | Contacts map 1:1 between Salesforce and GoHighLevel with straightforward field matching for standard fields like name, email, and phone. |
| Leads | medium | GoHighLevel has no separate Lead object, so Salesforce Leads must be merged into Contacts with tags or custom fields to preserve lifecycle stage segmentation without creating duplicates. |
| Accounts / Companies | medium | GHL Companies have limited functionality compared to Salesforce Accounts — no direct pipeline association and limited workflow triggers — and CSV exports risk silently duplicating company data across contacts. |
| Opportunities | medium | Opportunities must be mapped into GHL Pipelines with pre-created stages, and key native fields like CloseDate have no GHL equivalent, requiring custom field creation and stage ID translation. |
| Custom Objects | high | GoHighLevel's hard cap of 10 Custom Objects per location forces significant architectural compromises for Salesforce orgs with more than 10 active custom objects, requiring flattening or external archival. |
| Custom Fields | medium | All target custom fields must be pre-created in GoHighLevel before import, formula fields require pre-computation, and type mismatches between picklists, multi-selects, and date fields require explicit mapping. |
| Tasks / Activities | medium | Salesforce Tasks and Events must be split across GHL Tasks, Notes, and Appointments based on context, and historical activities are best stored as Notes since GHL has no unified activity history equivalent. |
| Record Types | medium | GoHighLevel has no Record Type equivalent, requiring Salesforce Record Type segmentation to be replicated through tags or custom dropdown fields, which reduces filtering and reporting fidelity. |
| User Ownership / Assignments | medium | Owner IDs must be mapped via a user crosswalk table rather than display names, and Salesforce queues and assignment rules have no direct GHL equivalent, requiring workflow-based alternatives. |
| Lookup Relationships | high | GHL uses shallow object associations instead of Salesforce's lookup and master-detail relationships, and lookup fields cannot be marked as unique, requiring concatenated text key workarounds to preserve referential integrity. |
The hard parts
What makes this specific migration difficult, beyond the mechanics.
Relational to Flat Model
Salesforce's deeply relational schema with Account → Contact → Opportunity hierarchies must be collapsed into GoHighLevel's contact-centric flat model, destroying native parent-child relationships and requiring synthetic key strategies to preserve referential integrity.
Custom Object Hard Cap
GoHighLevel enforces a limit of 10 Custom Objects per location across all plans, forcing Salesforce orgs with more than 10 active custom objects to flatten, archive, or externalize data that cannot fit within the native schema.
Lead Object Consolidation
GoHighLevel has no separate Lead object, so Salesforce Leads and Contacts must be merged into a single GHL Contact entity using tags or custom fields like lifecycle_stage to preserve segmentation.
Limited Unique Field Types
GHL custom objects only support uniqueness constraints on Single Line Text, Multi Line Text, Number, and Phone fields, meaning deduplication logic relying on dates or lookups must be handled entirely in the ETL layer before loading.
Formula Field Pre-Computation
GoHighLevel has no formula field equivalent, requiring all Salesforce formula field values to be pre-computed during the transformation phase and stored as static text or number custom fields.
Pipeline and Stage ID Mapping
Salesforce Opportunity stage names must be mapped to specific GoHighLevel Pipeline stage IDs, requiring pipelines and stages to be pre-created in GHL and a lookup table maintained to translate values during import.
What breaks
Known failure modes. Have a recovery plan for each before you cut over.
Tag-based routing
Zendesk relies heavily on comma-separated tags for routing, reporting, and categorization. Dumping tags into a Salesforce text field ruins reporting. You must convert structural tags into structured fields, Record Types, and Omni-Channel assignment rules.
Inline images and attachments
Zendesk stores attachments as URLs within comments. Salesforce requires extracting these files and uploading them as ContentVersion records linked via ContentDocumentLink.
Agent workflows
Zendesk Macros can insert text, change status, and add tags simultaneously. Salesforce splits this functionality across Quick Text, Flows, and native Macros.
Tools used in this playbook
All free, all run entirely in your browser — nothing is uploaded.
FAQ
Can I migrate Salesforce custom objects to GoHighLevel?
GoHighLevel supports up to 10 Custom Objects per location across all plans. If your Salesforce org has more than 10 active custom objects, you'll need to flatten some into custom fields on Contacts or archive them externally. Unique field constraints are limited to Single Line Text, Multi Line Text, Number, and Phone types — lookups and dates cannot be marked unique.
What are GoHighLevel's API rate limits for migration?
GoHighLevel's V2 API enforces a burst limit of 100 requests per 10 seconds and a daily limit of 200,000 requests, both scoped per Marketplace app per Location. The contacts endpoint returns a maximum of 100 records per request, requiring cursor-based pagination for larger datasets. The GET /contacts/ endpoint is deprecated — use POST /contacts/search instead.
Can I use Zapier to migrate data from Salesforce to GoHighLevel?
Zapier (via the LeadConnector app) works for real-time, record-level sync but is impractical for bulk historical migration. Each sub-account requires separate authentication, records process one at a time, and there's no support for rebuilding relational hierarchies like Account → Contact → Opportunity chains.
How do Salesforce Leads map to GoHighLevel?
GoHighLevel has no separate Lead object. Salesforce Leads should be merged into GHL Contacts during migration. Use tags or a custom dropdown field (e.g., lifecycle_stage = 'Lead') to distinguish them from converted Contacts.
Will a CSV import preserve Salesforce relationships in GoHighLevel?
No. CSV imports flatten relational data. Account → Contact → Opportunity hierarchies are destroyed because each object type imports independently with no cross-referencing. Use the GoHighLevel API to create records in dependency order and rebuild associations programmatically.