Understanding the Fullpath API
A non-technical overview for dealerships exploring integration with Fullpath.
What the Fullpath API Is
Fullpath provides an API (Application Programming Interface) that allows a dealership's own software systems to connect to Fullpath and exchange data. The API acts as a structured, secure channel between Fullpath and any other tool the dealership uses — a DMS, a CRM, a custom reporting dashboard, or a third-party integration built by a dealer group.
The API is not required to use Fullpath. The platform works entirely through the Fullpath dashboard. The API exists for dealerships or dealer groups that want to go further — pulling Fullpath data into other systems, sending data into Fullpath programmatically, or building custom automations beyond what the UI alone supports.
What Dealers Can Do With It
The Fullpath API exposes data across the core areas of the platform. The most common use cases group into four categories.
1. Shopper and audience data
Dealers can retrieve and search the shopper records Fullpath builds from website and DMS data. Common applications include syncing Fullpath shopper profiles into a dealer group's internal reporting or BI tool, looking up whether a specific contact (by email or phone) exists in Fullpath before taking an action elsewhere, and reading which Fullpath audiences a shopper belongs to so another system can act on that segmentation.
2. Leads, tasks, and appointments
Dealers can access structured lead, task, and appointment records. This supports building a custom reporting view that combines Fullpath lead data with internal sales results, feeding Fullpath lead activity into a centralized operations dashboard, and monitoring appointment records to confirm alignment between Fullpath and the DMS.
3. Consent management
Dealers can read, create, and update communication consent records for contacts. This is relevant for dealerships that manage opt-in and opt-out status from multiple sources (website forms, in-store sign-ups, email campaigns), that need to sync consent data between Fullpath and their own CRM or compliance tooling, or that want a programmatic way to record consent captured outside the Fullpath platform.
4. Activities
Dealers can pull activity records — the logged interactions and touchpoints Fullpath tracks for shoppers. This supports auditing engagement history for a specific shopper record and feeding activity data into a dealer-built reporting or analytics tool.
What the API Does Not Do
It is worth being clear about what falls outside the API's scope.
| Topic | What to know |
|---|---|
| Inventory management | The API does not manage or update inventory. Inventory data flows into Fullpath through existing DMS or feed integrations. |
| Campaign setup | Audience Activation campaigns are configured in the Fullpath dashboard. The API does not create or modify campaigns. |
| Ad account management | Paid Advertisement settings, budgets, and ad creative are managed in the dashboard, not through the API. |
| Real-time event streaming | The API uses a request and response model. It is not a live event stream or webhook system. |
| A dashboard replacement | The dashboard remains the primary interface for day-to-day use. The API supplements it for integration scenarios. |
MCP Tools: API Access for AI Assistants
In addition to the standard API, Fullpath publishes a set of MCP (Model Context Protocol) tools at developers.fullpath.com/mcp.html. MCP is an emerging standard that allows AI assistants and AI-powered tools to securely connect to external systems.
In practical terms: if a dealership is using or building an AI tool — a chatbot, an AI sales assistant, an internal AI agent — MCP tools let that AI access live Fullpath data to answer questions or take actions. The current MCP tool set covers the same core objects available through the standard API: shoppers, audiences, leads, appointments, tasks, and consent records.
Authentication: How Access Is Controlled
All API calls require authentication. Fullpath uses an API key system — a unique credential tied to the dealership account that must be included with every request.
Key things to know about API keys:
- An API key grants access to the dealership's data only. Keys are dealership-scoped, not platform-wide.
- API keys are confidential. Anyone with the key can read dealership data and write to consent records.
- API keys do not belong in public-facing code (websites, client-side JavaScript). Keys belong in server environments only.
- If a key is compromised, the dealership should contact their Fullpath Customer Success manager to rotate it immediately.
Who Should Implement the API
This is the most important section for a dealership manager evaluating an API integration. The right people for the work depend on the dealership's structure.
| Role | What they do |
|---|---|
| IT Director or Developer | The right person to actually implement the API. They write the code that calls the endpoints, handle authentication, and build the integration or reporting system. This is a technical role that requires programming experience. |
| Dealer group technology or digital team | Larger dealer groups with an in-house technology team can implement and maintain the integration themselves. They typically manage the API key securely and decide how to use the data downstream. |
| Third-party developer or integration partner | Many dealerships work with an outside developer or technology partner for custom builds. In that case, the API key and documentation go to the partner, not to dealership staff directly. |
| General manager or marketing manager | These roles define what problem the integration should solve (for example, "shopper data should appear in our BI tool"), but they do not implement it. They scope the work with their IT team or vendor. |
| Sales or BDC staff | No involvement needed. The API is a back-end integration tool and does not change how sales or BDC staff use Fullpath or their CRM day-to-day. |
Getting Started
For dealerships exploring the API, the typical path looks like this:
-
Identify the use case. Define what problem the integration solves, what data it needs, and where that data needs to go. The clearer the goal, the smoother the implementation.
-
Contact the Fullpath Customer Success manager. CS can confirm whether the API supports the use case, help with scoping, and provision the API key.
-
Have a developer review the full API documentation. Technical documentation — endpoints, request and response schemas, authentication details — lives at developers.fullpath.com. This guide is context; the developer documentation is the authoritative reference.
-
Build in a test environment first. Integrations should be tested with non-production data before going live against real shopper records or consent data.
-
Protect the API key. Store it securely (environment variables, a secrets manager) and never commit it to source code or share it by email.