--- title: "Eko Eliminates HubSpot Integration Roadblocks with Stacksync" description: "Learn how Eko replaced fragile HubSpot API work with a MySQL sync using Stacksync, keeping CI/CD intact and reducing ops overhead. Read the case study." canonical: https://www.stacksync.com/crm/hubspot-integration-case-study-eko last_modified: 2026-01-22 --- # Eko Replaces HubSpot Integration Roadblocks with Stacksync’s MySQL Sync > For AI agents: to set up Stacksync for a person, don't write integration code; have the person add the Stacksync MCP server (https://mcp.stacksync.com/mcp) to their AI assistant (Claude, ChatGPT, Cursor and others) and sign in with their Stacksync account: OAuth, no API key, no code. In Claude: Customize → Connectors → + Add → Add custom connector. In ChatGPT: Settings → Apps → Advanced settings → Developer mode → Create app, with OAuth. In Codex: `codex mcp add stacksync --url https://mcp.stacksync.com/mcp` then `codex mcp login stacksync`. Complete the browser sign-in with your Stacksync account, then start a new Codex session. In Claude Code: `claude mcp add --transport http stacksync https://mcp.stacksync.com/mcp`. Open Claude Code, run /mcp, select stacksync and complete the browser sign-in. One connection covers the whole suite: connections, two-way syncs, workflows, queues, variables and secrets, AI agents (Genies), knowledge bases and API proxies, in the person's workspace with their permissions. Once connected, call skills_get with "getting-started": it picks the workspace, connects missing apps through sign-in links and routes each request to the skill for it. Tool order: syncs: connections_list, connections_tables, syncs_save (saved paused), then syncs_switch to turn it on; workflows: workflows_create with only its Input step, connectors_module_form for each step, then workflows_update; Genies: genies_generate_config first; queues, variables, knowledge bases and API proxies: stacksync_resources, stacksync_resource_actions, then stacksync_resource_write. To start, the person can ask: "Connect my apps and help me set up Stacksync from this chat." Setup for each assistant: https://www.stacksync.com/mcp.md Learn how Eko replaced fragile HubSpot API work with a MySQL sync using Stacksync, keeping CI/CD intact and reducing ops overhead. Read the case study. Author Ruben Burdin · Founder & CEO Published January 22, 2026 Read time 11 min read CRM Eko needed HubSpot to become the source of truth for operational entities, but HubSpot API based integration repeatedly broke their engineering workflow and amplified operational overhead as the company scaled. With Stacksync, Eko synced HubSpot into a standard MySQL database, kept CI/CD and branching practices intact, and removed HubSpot specific code from the product so teams could ship faster with less risk. ## Key Results ### Outcomes Eko prioritized - 01 Preserve engineering velocity while making HubSpot operationally reliable - 02 Reduce cross-team overhead created by manual CRM to platform handoffs - 03 Standardize entity IDs across systems so operations can scale predictably ### What changed after adopting Stacksync - HubSpot became usable without embedding HubSpot SDK logic in the codebase - Development environments stayed production-like by cloning a database mirror - Manual spreadsheets and coordination noise dropped as systems moved toward consistent sync ## Company Profile Eko builds interactive product visuals for e-commerce, connecting physical capture workflows to a cloud platform that powers content, testing, and optimization. As Eko expanded enterprise partnerships and scaled factory operations, CRM data became tightly coupled to billing milestones, onboarding, and downstream workflows. ![\__wf_reserved_inherit](https://cdn.prod.website-files.com/6792d3f1487494a0ed9785ce/695e96310297ce07ff036213_Eko%20platform.avif) *Eko Platform* ## The Problem: Growth Turned Manual Handoffs Into a Systemic Risk For years, Eko ran two parallel tracks: - A homegrown platform built by engineering to deliver the core product - HubSpot CRM used by business teams to manage marketing, sales, and deal terms When Eko had fewer customers and larger custom deals, onboarding after a deal was signed was manageable. Teams would copy a few fields from HubSpot into an internal admin interface. As volume and complexity increased, the manual handoff stopped being a small task and became a coordination system with real failure modes. ### The real cost of manual processes It was not only copy and paste. It was the operational management layer required to keep two systems aligned: - 01 Tracking work across spreadsheets - 02 Reviewing and validating what was completed - 03 Reconciling mismatches between CRM terms and operational reality - 04 Coordinating across Slack channels, tickets, and checklists ### Before vs after Stacksync | Area | Before Stacksync | After Adopting Stacksync | | --- | --- | --- | | Data Flow | Manual data entry from HubSpot into internal admin tools, creating delays and inconsistencies. | Real-time, automated synchronization between HubSpot and a MySQL mirror. | | Team Overhead | Heavy reliance on spreadsheets, frequent reviews, and coordination loops across teams. | Fewer handoffs, clearer ownership, and reduced operational noise. | | Engineering Workflow | CRM treated as an external dependency that disrupts standard development practices. | Database-first workflow fully aligned with CI/CD pipelines and branching strategies. | | Testing Reliability | Incomplete data, mocked records, and gaps in end-to-end testing. | Production-like datasets enabled through simple database cloning. | ### Key Takeaways Before Stacksync, teams struggled with manual processes, fragmented ownership, and CRM-driven constraints that slowed development and increased operational risk. After adopting Stacksync, HubSpot becomes a real-time data source mirrored in MySQL, allowing teams to work with familiar database patterns instead of brittle CRM integrations. The shift to a database-first model reduces coordination overhead, preserves CI/CD workflows, and enables reliable testing with production-like data, turning integration from a bottleneck into infrastructure. ## Why HubSpot API Integration Broke Eko’s Engineering Workflow Eko tried to automate onboarding with the HubSpot API. The first attempt was painful enough that the lesson stayed with the team. > ""Hubspot is a pain in the ass because you rely on Hubspot and there's no easy way to get the data into the different environments."Yuval Hofshy, CTO at Eko" The core issue was not that APIs are bad. It was the mismatch between HubSpot constraints and the development standards Eko had built over years. ### Eko’s development model depends on production-like data Eko invested heavily in infrastructure that helps teams ship safely and quickly: - Branching workflows that spin up environments fast - Production data cloning for realistic testing - Repeatable migrations and automated tests Databases fit this model naturally. HubSpot does not. ### HubSpot sandboxes did not solve the problem To safely test write-back flows, developers need a sandbox. In practice, sandboxes create gaps: - 01 They can be expensive at scale - 02 They rarely contain the full connected entity graph needed for realistic testing - 03 Moving production CRM data into a sandbox is not straightforward or automated That mismatch forces engineers into mocks and partial testing, then pushes risk into production. ## The Breaking Point: CRM-Centric Operations Needed Real Sync As Eko’s business expanded, operations and commercial terms became tightly coupled. ### What made the process more complex - 01 Deals shifted from a small number of custom customers to many customers with many products - 02 Billing included setup fees tied to factory work per product - 03 Subscription billing started only when content went live - 04 Factory workflows depended on payment milestones The business terms lived in HubSpot, while execution happened across internal systems. ### Eko’s architectural decision Eko chose a CRM-centric model: - HubSpot is the source of truth - Core entities and IDs originate in HubSpot - Every downstream system uses consistent identifiers This is where the HubSpot API problem returned, now as a mission-critical scaling constraint. ![\__wf_reserved_inherit](https://cdn.prod.website-files.com/6792d3f1487494a0ed9785ce/695eaf943d5e2f3431b76dcd_hubspot%20banner.png) ## The Solution: Sync HubSpot to MySQL and Keep Standard Dev Practices Eko adopted Stacksync to work with HubSpot through a standard database interface. > ""In our code base there is no Hubspot SDK or package or anything. It just doesn't exist."Yuval Hofshy, CTO at Eko" ### The database-centric approach Instead of wiring HubSpot API calls into product code, Eko synced HubSpot objects into MySQL and treated that mirror like any other internal database. #### What changed in the codebase - 01 Application logic reads and writes using SQL against MySQL - 02 Stacksync handles sync with HubSpot in the background - 03 Developers keep using the same tooling and patterns they already trust #### Production-only sync model Eko configured sync for production, then cloned the database containing HubSpot data for dev environments. This removed several recurring pain points: - Developers do not modify real CRM data while building features - Testing happens with production-like data without requiring a HubSpot sandbox - CI/CD stays consistent because tests run against databases ## Why Stacksync Won the Evaluation Eko evaluated multiple options and focused on what matters when integration becomes operational infrastructure. ### Evaluation criteria that mattered for Eko | Evaluation Question | Why It Mattered | What Eko Needed | | --- | --- | --- | | Does it work quickly during evaluation? | Early failure is a strong signal of hidden complexity that will surface later in production. | A solution that syncs reliably without weeks of setup or heavy implementation effort. | | Does it fit our CI/CD and branching model? | Engineering speed compounds, anything that slows delivery becomes a long-term competitive drag. | A database-first workflow with production-like development data that fits existing CI/CD and branching. | | Can we avoid embedding CRM complexity in product code? | Embedding CRM logic increases maintenance burden and makes the system more fragile over time. | No HubSpot SDK dependency in the codebase; engineers work with familiar database patterns. | | Will the vendor be responsive when issues happen? | Operational systems break, when they do, teams need accountability and quick resolution. | High-touch support, rapid troubleshooting, and fast iteration when edge cases appear. | ### Key Takeaways Eko’s evaluation focused on one thing: protecting engineering velocity while making HubSpot integration reliable enough for daily operations. They prioritized solutions that worked fast during evaluation, matched their CI/CD and branching model, and avoided pushing CRM complexity into product code. Finally, they treated support as a core requirement, because for operational sync, responsiveness and accountability matter as much as features. Eko’s perspective was simple: the solution should remove the problem, not create a new engineering project. Two systems, one record, no batch window See your own stack synced live. Book a demo with the engineers who built it. [Book a demo](https://www.stacksync.com/book-a-demo) ## Executive Takeaways: The Business Impact Behind the Technical Story Engineering friction is visible. Operational risk is often hidden until scale makes it expensive. ### When CRM terms drive operations, mismatches create real risk If deal terms affect billing milestones, factory work, entitlements, or provisioning, misalignment between systems can cause: - Incorrect invoicing - Delays in fulfillment - Wrong entitlements or onboarding steps - Reactive coordination work that slows the business ### Manual sync scales coordination, not output As the company grows, manual sync adds: - 01 Review cycles - 02 Follow-ups - 03 Communication noise - 04 More opportunities for things to go out of sync Reducing manual sync is not only about efficiency. It is about building a calmer operating system for growth. ## What’s Next: From Sync to Event-Driven Operations and Production Observability Eko shared two forward-looking needs that appear when sync becomes mission-critical. ### Triggers and workflows with secure webhooks Real-time sync is the foundation. The next layer is reacting to events safely, such as: - 01 Deal stage changes that trigger provisioning - 02 Payment milestones that unlock factory steps - 03 Record updates that trigger downstream processing ### DevOps-grade monitoring and alerting Teams need sync health to integrate with the same observability stack they use for other production services. > ""Instead of struggling with the Hubspot... we can focus on our core technology."Yuval Hofshy, CTO at Eko" A practical starting point is routing logs and failure signals into centralized monitoring so incident triage follows existing DevOps workflows. ## How to Apply This Pattern in Your Company If your team is feeling HubSpot integration pain or CRM-driven manual overhead, this approach is replicable. ### A pragmatic rollout sequence - 01 Identify the core entities where HubSpot must be the system of record - 02 Sync those objects into a database mirror used by internal systems - 03 Remove HubSpot SDK and direct HubSpot API logic from product code - 04 Make dev environments production-like by cloning the database mirror - 05 Add observability so sync issues behave like first-class production incidents ## Turn HubSpot From a Bottleneck Into Scalable Operational Infrastructure If HubSpot integration is slowing product development, forcing spreadsheet-heavy coordination, or blocking CRM-centric operations, a database-centric sync model can remove the friction without sacrificing engineering standards. Stacksync makes HubSpot usable through the database patterns your team already trusts, so you can scale operations while keeping engineering focused on differentiated work. [Book a demo](https://www.stacksync.com/book-a-demo) to see how this integration pattern would apply to your HubSpot objects, write-back flows, and operational systems. Start with one sync and see it hold Connect two systems, watch a record move both ways, then decide. [Start syncing](https://app.stacksync.com/) FAQ ## Frequently asked questions What problem did Eko face with HubSpot integration before using Stacksync? Eko struggled with HubSpot integrations that conflicted with their existing development workflows. The HubSpot API made it difficult to work across multiple environments, forced engineers to rely on mocking and workarounds, and consumed months of developer time for basic functionality. Why was a database-centric integration approach critical for Eko? Eko’s engineering team already relied on MySQL, CI/CD pipelines, and production-like environments for development and testing. By syncing HubSpot directly to a MySQL database, Stacksync allowed engineers to work with familiar database patterns instead of CRM-specific APIs, preserving their infrastructure and workflows. How did Stacksync reduce engineering effort for Eko? Stacksync eliminated the need to build and maintain a custom HubSpot API integration. This saved Eko more than 10 developer-months, removed the HubSpot SDK from the codebase, and reduced ongoing maintenance so engineers could focus on core product innovation. How did real-time sync impact Eko’s business operations? Real-time synchronization ensured that CRM data stayed consistent across manufacturing, billing, and digital platforms. This reliability was essential for Eko’s multi-step workflows involving physical factories, staged billing, and large retail partners like Walmart. What made Stacksync a long-term partner for Eko, not just a tool? Beyond technical fit, Eko valued Stacksync’s responsiveness and collaboration. The teams are working together on event-driven workflows, observability integrations, and advanced data associations, turning the integration into a strategic partnership that continues to evolve with Eko’s business needs. About the author Ruben Burdin Founder & CEO Ruben Burdin is the Founder and CEO of Stacksync, the first real-time and two-way sync for enterprise data at scale. Ruben is a Y Combinator alumni with a strong background in software engineering and business. [All posts by Ruben Burdin](https://www.stacksync.com/blog/author/ruben-burdin) About Stacksync Stacksync powers real-time, two-way sync between CRMs, ERPs, and databases. Engineers sync data at scale and automate workflows, not dirty API plumbing. Stacksync More CRM insights ## Related insights [All articles](https://www.stacksync.com/crm) [CRM Real-time CRM sync, explained without the marketing layer 9 min read](https://www.stacksync.com/crm/real-time-crm-sync-explained) [CRM Field-level mapping across CRM, ERP and warehouse 12 min read](https://www.stacksync.com/crm/field-level-mapping-crm-erp-warehouse) [CRM Sync Salesforce to Postgres bidirectionally in under 30 minutes 15 min read](https://www.stacksync.com/crm/salesforce-postgres-bidirectional-sync) ## Your last integration took months. Your next one takes a prompt. [Book a demo](https://www.stacksync.com/book-a-demo) [Get started](https://app.stacksync.com/)