A ChatGPT integration can connect an authorized business service to ChatGPT, place an AI agent on your website, add model-assisted behavior to your own product, or expose an internal service through the Apps SDK and MCP. These are different implementation paths. Choose by where the user works and where the result must go, not by the model name.
A sales representative who wants to review a HubSpot deal inside ChatGPT needs a connected app. A visitor asking about returns on your website needs a website agent. A product team adding an assistant to its own application needs an API feature. Developers who want employees to query an internal policy service from ChatGPT can assess an Apps SDK and MCP app.
This guide helps you choose and design a route. It is not a universal copy-and-paste installation recipe. Permissions, supported actions, plan restrictions, data handling, and availability must be checked for the specific deployment.
What does ChatGPT integration mean, and which path fits your goal?
A connected app used inside ChatGPT is not the same as a chatbot embedded on a website. The paths may use related AI capabilities, but they have different users, interfaces, permissions, and operational owners.
| Path | Where it runs | Best fit | Typical owner |
|---|---|---|---|
| Connected app | Inside ChatGPT | Authorized business data or supported actions | Workspace and app administrator |
| Website agent | Your website | Visitor answers, guidance, or support handoff | Website and support teams |
| Custom API feature | Your product or backend | Application-controlled model behavior | Product and engineering |
| Apps SDK and MCP | Inside ChatGPT, backed by your service | An internal tool or service in ChatGPT | Developers and workspace administrator |
Connected app
The user works in ChatGPT and authorizes an external service. Provider permissions, app capabilities, and workspace controls determine what the connection can access or change.
Website agent
The visitor works on your site. Your team defines approved sources, answer boundaries, escalation routes, and any permitted actions.
OpenAI’s connected-app documentation explains how provider authorization, app capabilities, and workspace controls affect connected services. Terminology and navigation can change, so use the current vendor documentation during setup.
Path 1: Connect an existing business app to ChatGPT
A connected app can let an authorized user retrieve information from a service and, where supported, request actions. Access depends on the connected account, app capabilities, user permissions, and administrator settings. One CRM connector should not be treated as a model for every other connector.
HubSpot as a documented example
HubSpot documents a connector that requires Super Admin approval, selected data permissions, and controls over which users may install it. An authorized user then connects their account and asks ChatGPT to retrieve permitted CRM context or perform a supported action. For supported writes, the user may review and confirm the proposed change. HubSpot also documents attribution for supported write actions and visibility into connector connection activity.
The documented constraints matter. HubSpot API limits apply, bulk create and update operations are limited to 10 records per request, and custom validation rules are not applied through the connector. Custom objects, unstructured data, associated engagements, and sensitive data properties are also subject to the documented access restrictions. A connector write therefore is not equivalent to an update submitted through every normal CRM form and rule.
- Start with read-only research on a known contact, deal, or ticket.
- Test one record before considering broader actions.
- Show the record identifier, current value, proposed value, and reason before confirmation.
- After the action, inspect the destination record and available audit attribution.
Keep separate application rules or human review for deal stage, ownership, monetary, legal, lifecycle, and customer-facing changes. See HubSpot’s current connector setup and limitations. For permission mapping and workflow ownership, see HubSpot systems and workflow support.
Path 2: Put an AI agent on a website
A website agent is usually provided by a third-party platform. It is not automatically ChatGPT itself or a direct OpenAI API implementation. Chatbase, for example, describes a model-agnostic agent platform with website deployment, knowledge sources, integrations, analytics, procedures, and human handoff.
Begin with a defined job on a few high-intent pages, such as product, support, or checkout pages. Specify the approved sources, permitted topics, response behavior when information is missing, and the route to a person. For live prices, stock, account-specific changes, or other volatile data, use a verified deterministic source or an authorized process instead of relying on stale page text.
A bounded support flow could be: visitor asks about a return, the agent retrieves the approved returns policy, the agent answers with the relevant policy or offers handoff, and support receives unresolved requests through the configured channel. Assign an owner to check source freshness and review unsupported-answer reports. Measure resolution, escalation, unsupported answers, and user feedback rather than message volume alone.
Chatbase describes its capabilities on its product overview and procedures page. Its current public pricing page displays a free plan and higher-priced paid plans, but prices, credits, limits, and included features can change. Check the current plan page before promising a source limit, action, model, or channel. For help defining the agent’s job, sources, and escalation process, see AI agent implementation and operational design.
Path 3: Build a custom website or product feature with the API
A custom API feature gives your application control over authentication, context, output handling, and business rules. A safe baseline architecture is browser widget, authenticated application backend, model API, backend validation and response handling, then browser response or human escalation. The backend, not browser or mobile-app code, holds the API key.
For a support classifier, an illustrative output contract could look like this. It is an editorial design example, not a vendor schema:
{
"record_id": "crm-4821",
"field_name": "support_category",
"proposed_value": "delivery_address",
"evidence": "The customer asks to change the delivery address.",
"confidence": 0.91,
"needs_human_review": true
}The backend should reject unknown fields, invalid types, missing required values, and confidence values outside the permitted range. If the result could change an account or CRM record, route it through the write gate below.
OpenAI’s API-key guidance and key-safety guidance support backend routing, environment variables or key-management services, access controls, monitoring, rotation, and spend controls. The official Responses API starter app demonstrates application structure, streaming, tools, and integrations, but it does not establish your production authentication, tenant isolation, CRM validation, abuse prevention, or compliance controls. Use the current production best-practices documentation when planning deployment.
Choose conversation state according to context requirements, privacy, latency, and cost. A fixed history length is an implementation choice, not a universal rule. Review retention, processing location, and legal obligations for the actual data and jurisdictions involved.
Path 4: Expose an internal service through an Apps SDK or MCP app
The Apps SDK is a developer route for building apps that run inside ChatGPT and connect to backend logic, including MCP-based tools. It is not a no-code connector. The request path is ChatGPT request, declared tool, authenticated internal backend, permitted operation, and structured result returned to ChatGPT.
A controlled rollout is to build the app, test it in developer mode, define narrow actions and permissions, assess the MCP server and authentication model, obtain workspace review where required, and publish only after an internal owner accepts the data and action scope. Start with read-only tools. Add a write action only after authorization, confirmation behavior, conflict handling, and failure handling are defined.
OpenAI documents workspace controls including RBAC and action controls for Enterprise and Edu workspaces. Availability and controls depend on workspace type and rollout, and some actions may require confirmation. The organization remains responsible for assessing the safety and suitability of the MCP server. See the Apps SDK documentation and developer mode and MCP app controls.
A policy-search tool illustrates the boundary: it accepts a question, checks the user’s authorization in the backend, retrieves approved policy text, and returns a structured result. If authorization fails or no current policy is found, it returns an unavailable result for the named service owner to investigate rather than inventing a policy answer.
Put a validation gate between AI output and business actions
Use AI to interpret unstructured text or propose a classification. Use ordinary application rules for permissions, calculations, fixed enumerations, exact routing, and legally or financially consequential decisions. The model can draft a patch. Your application decides whether that patch is valid and allowed.
A connector that can write to a CRM is not necessarily applying the CRM’s normal form validation. HubSpot specifically says custom validation rules are not applied through its ChatGPT connector. Preview the exact record and values, validate the proposed patch in deterministic logic, and require approval for consequential changes.
For a CRM write, use this sequence: identify the record, read its current values, produce a proposed patch, validate field names, types, allowed values, authorization, and business rules in code, require human approval when risk warrants it, write only the approved patch, then read the record back and log the outcome. If the record changed after the initial read, stop and resolve the conflict rather than silently overwriting it.
Keep separate records for separate events. One inbound source event is not the same as a model run, citation, destination write, or aggregate report. A practical audit design stores:
- One inbound-event row for each source event, keyed by source system, source event ID, and event type.
- One model-run row for each model invocation, including retries, with a unique run ID, model, prompt or policy version, timestamp, and outcome.
- One citation row for each cited source, keyed by run ID plus citation ordinal or canonical source identifier.
- One write-attempt row for each destination mutation, including destination record ID, field, previous value, proposed value, approver, external request ID, and result.
- One aggregate row at the defined reporting scope, such as brand, query set, model variant, geography, and reporting period. It must not be used as a substitute for raw events.
For duplicate handling, enforce a database uniqueness constraint on the source system, source event ID, and event type. Where supported, use a transactional upsert or destination idempotency mechanism. A lookup-then-create check alone is not race-safe when two workers process the same event concurrently. If a write fails or times out, check destination state before retrying and do not blindly repeat a non-idempotent action.
Test the chosen path and measure whether it works
Test ordinary requests and the cases that break the workflow: ambiguous or unsupported questions, malformed input and output, permission denial, rate limits, timeouts, stale information, duplicate events, and human handoff. For write paths, also test rejected approval, two competing updates, safe retries, partial failure, and an unavailable destination.
Choose a measure that matches the job. A support agent can be assessed on resolution, escalation, unsupported-answer rate, and feedback. An internal assistant can be assessed on task completion and correction rate. A CRM action can be assessed on validated write success, errors, reversals, and time to correction. Record a baseline, run a bounded pilot, inspect failures and human corrections, then expand only when an owner can support the workload.
- Representative, ambiguous, unsupported, malformed, and permission-failure cases have been tested.
- Every permission and allowed write action has a named owner.
- Duplicate events, retries, conflicts, partial writes, and destination outages have defined handling.
- Human escalation reaches a monitored queue or person.
- A baseline and a job-specific success measure are recorded.
Choose the route that matches the user and destination. Keep the model’s responsibility bounded, make validation deterministic where the consequence is high, and expand only after the application or operator can verify the result. Check current official vendor documentation before setup because feature availability, plan limits, permissions, pricing, and terminology can change.