canonical: https://jentic.com/apis/hubapi.com/hubspot-crm-cards

# HubSpot CRM cards

Jentic publishes the only available OpenAPI specification for CRM cards, keeping it validated and agent-ready. The HubSpot CRM cards API lets developer apps extend the CRM record sidebar by registering custom cards that pull data from external systems when a user opens a contact, company, or deal record. Cards are configured up-front per app and populated at view time by an external data fetch URL the app exposes. This is the building block for embedding third-party context - order history, support tickets, billing - directly in the HubSpot CRM UI.

## For AI agents

Register and manage HubSpot CRM sidebar cards that surface external data on contact, company, and deal records inside the HubSpot UI.

## Scope

Does not read or write CRM record data, manage contacts, or send emails - use only for registering and managing CRM sidebar cards.

## Capabilities

- Register a new sidebar card for a HubSpot app via POST /crm/v3/extensions/cards/{appId}
- List every card configured under an app with GET /crm/v3/extensions/cards/{appId}
- Inspect a single card's configuration through GET /crm/v3/extensions/cards/{appId}/{cardId}
- Update a card's display label, fetch URL, or object types via PATCH /crm/v3/extensions/cards/{appId}/{cardId}
- Remove an obsolete card with DELETE /crm/v3/extensions/cards/{appId}/{cardId}
- Inspect the expected card detail response shape via GET /crm/v3/extensions/cards/sample-response

## Use cases

### Embed External Order History in HubSpot Records

Surface a customer's recent orders from an internal e-commerce database directly on the HubSpot contact record. Register a card with POST /crm/v3/extensions/cards/{appId} pointing at an external fetch URL; HubSpot calls that URL when a sales rep opens the record and renders the returned tiles in the sidebar.

Example prompt: POST a new card with title Recent Orders and a fetch URL pointing at the orders service, scoped to the contact and deal object types.

### Manage Card Lifecycle Across Environments

Promote a card configuration from staging to production by listing all cards under an app, inspecting the relevant one, and updating the fetch URL. PATCH /crm/v3/extensions/cards/{appId}/{cardId} accepts partial updates so the card label and URL can move between environments without re-registering.

Example prompt: GET all cards on app 12345, find the one titled Subscriptions, and PATCH its fetchUrl to the production endpoint.

### Validate Card Response Shape Before Deploy

Before publishing a card, hit GET /crm/v3/extensions/cards/sample-response to retrieve the canonical response shape HubSpot expects, then compare it to the JSON the external service is returning. This eliminates the most common cause of cards rendering empty: shape mismatches.

Example prompt: GET /crm/v3/extensions/cards/sample-response and run a JSON-schema diff against the external service's actual response.

### AI Agent Card Provisioning via Jentic

An AI agent rolling out a new HubSpot integration can call Jentic to discover and execute the CRM cards endpoints - registering, configuring, or removing cards programmatically as part of an app's onboarding flow.

Example prompt: Search Jentic for create a hubspot crm card, load POST /crm/v3/extensions/cards/{appId}, and execute with the card title and fetch URL.

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| POST | /crm/v3/extensions/cards/{appId} | Create a new card for an app |
| GET | /crm/v3/extensions/cards/{appId} | List all cards for an app |
| GET | /crm/v3/extensions/cards/{appId}/{cardId} | Get a single card |
| PATCH | /crm/v3/extensions/cards/{appId}/{cardId} | Update a card |
| DELETE | /crm/v3/extensions/cards/{appId}/{cardId} | Delete a card |
| GET | /crm/v3/extensions/cards/sample-response | Get the sample card detail response shape |

## Key resources

- **Cards** — Create, read, update, and delete HubSpot CRM sidebar cards
- **SampleResponse** — Reference response shape that external fetch URLs must match

## Why Jentic

- **Setup:** Wiring HubSpot CRM cards by hand means setting up its hapikey query auth, keeping the api.hubapi.com host straight across the extension-card endpoints, and handling errors yourself. Through Jentic you install once, import CRM cards from the API Directory, store the key once, and your agent calls it.
- **Permission scoping:** CRM cards puts the app id in the URL path (/crm/v3/extensions/cards/{appId}), so a rule can pin your agent to one app: it can create and read cards for that app and nothing else. You choose the operations it may call, so patching or deleting cards is not included unless you add them.
- **Credential handling:** Your HubSpot developer hapikey is stored once, encrypted, by your own Jentic One instance and injected as the hapikey query parameter at execution time. It never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'register a HubSpot CRM card' or 'list my extension cards', and Jentic returns the matching CRM cards operation with its input schema so the agent calls the right endpoint without browsing the reference docs.

## Related APIs

- **HubSpot CRM API** — Underlying HubSpot CRM objects (contacts, companies, deals) that cards are surfaced on
- **HubSpot Custom Workflow Actions** — Another HubSpot extension surface for embedding app logic, but in workflows rather than record sidebars
- **HubSpot Webhooks API** — Subscribe to CRM record events instead of pulling on view via cards

## FAQ

### Why is there no official OpenAPI spec for CRM cards?

HubSpot does not publish an OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call CRM cards via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer.

### What authentication does the CRM cards API use?

The CRM cards API uses HubSpot developer hapikey authentication, passed as a query parameter named hapikey. Through Jentic, the key is held in the encrypted vault and injected at execution time so it never enters the agent context.

### Can I register a new sidebar card programmatically?

Yes. POST a card definition to /crm/v3/extensions/cards/{appId} with the card title, the fetch URL HubSpot should call when rendering, and the object types (contact, company, deal) the card should appear on.

### What are the rate limits for the CRM cards API?

HubSpot applies the standard developer-key rate limits across CRM extensions endpoints. Limits depend on app tier and are not in the spec - consult the HubSpot developer dashboard for current per-app limits before bulk card operations.

### How do I update a CRM card's fetch URL through Jentic?

Search Jentic for update a hubspot crm card, load PATCH /crm/v3/extensions/cards/{appId}/{cardId}, and execute with the new fetchUrl in the request body. Jentic injects the developer hapikey from the vault.

### How do I know what JSON shape my fetch URL should return?

Call GET /crm/v3/extensions/cards/sample-response. It returns the canonical response shape HubSpot expects, which is the most reliable reference when building or debugging a card's data service.

### Can I limit what my agent is allowed to do with the HubSpot CRM Cards API?

Yes. Because you run Jentic One yourself, your own rules decide which CRM cards operations and credentials the agent may use. Since the app id sits in the path (/crm/v3/extensions/cards/{appId}), a rule can pin the agent to a single HubSpot app so it only creates and reads cards for that app and touches nothing else. You choose the operations it may call, so patching or deleting cards stays off the table unless you explicitly add those endpoints.