Most CRM buying guides review dashboards. This one reviews the plumbing. A REST API CRM is what your AI agents actually touch; the UI is just where humans peek in. If agents will run enrichment, outreach, and pipeline updates, judge the API before you sit through a single demo.
The stakes are higher than they used to be. Agents don't click buttons. They fire API calls by the thousand, at hours when nobody's watching, and no sales deck will mention rate limits or idempotency keys. Those unglamorous details decide whether your automations survive their first week in production.
This guide covers the checks that matter: required endpoints, durability features, rate limits, and where MCP fits. It's written for anyone hunting the best CRM for technical founders, or anyone tired of scattered API-doc pages. By the end you'll have a rubric for scoring any REST API CRM, plus a six-step plan for your first agent workflow.
Why developers evaluate CRMs by API before UI
A CRM's UI serves people. Its API serves everything else: integrations, syncs, scripts, and now agents. Once agents do the data entry, the API is the product.
The UI improves every quarter. A weak API taxes you for the life of the contract. So read the developer docs first, before the demo and before anyone on the team gets attached to a pipeline view.
What should you look for in a REST API CRM as a developer? Four early signals:
- A machine-readable spec. An OpenAPI file makes SDKs, codegen, and agent tooling work out of the box.
- A public changelog. You need to see breaking changes before they hit production.
- A deprecation policy. How long do endpoints live after they're marked deprecated?
- A sandbox. You should test writes without touching real pipeline data.
Thin docs usually mean the API is an afterthought. That debt compounds once agents depend on it.
What a REST API CRM must expose: contacts, deals, activities, and enrichment
Contact CRUD alone won't carry an agent workflow. Check these endpoint groups before committing.
- Contacts and companies. Create, read, update, search. Look for upsert support and dedupe on natural keys like email.
- Deals. Pipeline and stage changes, so an agent can move records without the UI.
- Activities. Notes, emails, calls, meetings, tasks. Agents read this trail to reconstruct context.
- Search. Filtered, paginated queries. Watch the limits here. HubSpot flags its search endpoints as stricter than its general limits, and practitioners pin them near 4 requests per second.
- Enrichment. Native enrichment endpoints, or clean custom-field writes so agents can store firmographics they gather.
- Events. Webhooks for change capture, so agents react instead of polling. HubSpot notes webhook calls from workflows don't count against its API rate limits.
Batch endpoints deserve a close look. Bulk jobs are where limits bite. HubSpot's batch endpoints handle up to 100 records per call, and its guidelines recommend batching.
Can AI agents write to a CRM through its API? Yes, that's the point. Safe writes, though, need the durability features below.
Durability and state: execution histories, idempotency, and retries
Agents fail mid-run. Networks drop. Retried LLM steps return different outputs. A REST API CRM has to survive all three.
Idempotency. An idempotency key lets you retry a failed POST without creating a duplicate. Ask whether the vendor documents one. Many don't. HubSpot's usage guidelines spell out rate limits in detail but say nothing about idempotency keys. If support is undocumented, build dedupe in: upsert on email, or search before create.
Retries. Treat 429 and 5xx responses as normal traffic. Exponential backoff with jitter is the minimum pattern. Without jitter, parallel workers retry in lockstep and re-trigger the limit. Respect any Retry-After header the API returns.
Rate limits. Demand published numbers, then test them. HubSpot is a useful benchmark: public OAuth apps get 110 requests per 10 seconds per installing account. Private apps get 100 to 190 per 10 seconds by tier, with daily caps between 250,000 and 1,000,000. Cross a line and every call returns a 429 until the window resets.
Execution histories. The CRM records outcomes; it rarely records how a run produced them. Agent workflows need a durable log of each execution: inputs, tool calls, outputs, errors. Without it you can't debug a run or resume one safely. Some platforms for AI agents ship run histories natively. Zrevick, for instance, stores durable data states and execution run histories alongside its CRM objects, so a failed run becomes a resume rather than a mystery.
Otherwise, build a runs table yourself: run ID, step, payload, result, timestamp. Make every step resumable from the last recorded state.
MCP vs raw REST: when to use each from an agent
How do MCP and REST APIs differ for CRM automation? Short version: REST is for code you control; MCP is for agents that explore.
With raw REST, you hard-code endpoints, auth, and call order. That suits deterministic pipelines: nightly syncs, scheduled enrichment, anything payment-adjacent. You own every call. Behavior is predictable.
With MCP, the agent discovers capabilities at runtime from a server that describes its tools. You say "find warm leads and draft follow-ups." The agent chains the calls itself. That suits open-ended, multi-step work where the call sequence isn't predictable.
Two practical notes:
- An MCP server for CRM tools almost always wraps the same REST endpoints. MCP inherits that API's weaknesses: limits, dedupe gaps, flaky auth. Whichever surface you use, you're still depending on the same REST API CRM underneath. Evaluate that layer regardless.
- Check whether the CRM ships an official MCP server. If not, the wrapper becomes your maintenance burden.
A hybrid works well in practice. Expose a small, curated MCP toolset for agent decisions. Keep deterministic REST code for the writes. The agent picks what to do; your code decides how to do it safely.
Comparing API quality across modern CRMs
Which REST API CRM comes out ahead? Skip the marketing pages and score candidates on one rubric:
- Published rate limits and error budgets
- Batch endpoints for bulk operations
- Webhooks for change capture
- Idempotency documentation
- A changelog with advance notice of breaking changes
- An official MCP server
HubSpot does well on transparency. Its limits are published by tier. Its guidelines recommend batch APIs and caching. It also promises advance notice of API changes through its developer changelog. Weak spots: search endpoints are throttled harder than the general limits, and marketplace apps must keep error responses under 5% of daily requests.
Salesforce, Pipedrive, and Attio all publish REST APIs too. Score each REST API CRM on the same rubric. Then read their last six months of changelogs. Breaking changes there predict your maintenance load better than any feature list.
Finally, ask whether the CRM is built for agents at all. A traditional CRM with a solid API still leaves you assembling a platform for AI agents piece by piece: the queue, the run history, the enrichment, the outreach tooling. Newer entrants bundle those. Zrevick exposes its CRM, lead enrichment, and outreach through both REST and MCP. Every plan includes unlimited AI agents. The Starter tier runs about $34 a month, billed annually, with a 10,000-lead allowance. For teams comparing options, API depth plus native agent infrastructure is the combination worth testing.
Building your first agent workflow against a REST API CRM
Pick one small, closed loop. Example: new signup → enrich → upsert contact → log activity → move deal.
Then build it in six steps.
- Auth. Use OAuth where it's offered. Store refresh tokens. Don't treat a 401 as proof a token expired; HubSpot's docs note 401s aren't a valid signal for that.
- Read. Fetch the signup and its context. Cache what you can; repeated reads burn limits.
- Decide. Let the agent choose the action: stage, message, owner. Keep this step isolated and logged.
- Write. Upsert keyed on email. Wrap every call in retry with backoff and jitter. Check rate-limit headers before firing the next batch.
- Log. Record inputs, outputs, and API responses per step. That's your execution history.
- Verify. Read back what the agent wrote. A cheap GET catches wrong stages and duplicates before your team does.
Add guardrails on day one:
- A dry-run mode that logs intended writes without executing them
- A daily write cap per agent
- An alert when failures pass a threshold; HubSpot's 5% marketplace bar is a sensible starting point
- A kill switch per workflow, not per API key
Run the loop in dry-run for a week. Promote it only when the write log matches what you'd have done by hand.
Score the REST API CRM before the demo
A CRM you'll drive with agents is infrastructure, not software. Read the docs before the demo. Hit the rate limits on purpose. Ask about idempotency and run histories on the sales call; the pause you get is data.
Zrevick was built for exactly this evaluation: one workspace where REST and MCP access, durable run histories, and unlimited agents are the baseline. Take the same rubric to every vendor on your shortlist, including us.