What disconnected systems are costing you
Somewhere in your business, a person spends part of their week moving information from one tool to another by hand. A customer pays, and someone copies that payment into the accounting sheet. A signup comes in, and someone adds it to the CRM. A shipment goes out, and someone types the tracking number into three places.
None of that work grows your business. It is the cost of your systems not talking to each other.
I have spent 17 years building software, with 250 plus projects shipped. The largest piece of that work was at bolttech, a $1B+ fintech, where I led the Payment Service that connected 40+ payment providers behind one system. So I have seen what this costs a business up close, and I have seen what it saves once the systems talk on their own.
This guide covers what an API integration actually is, in plain terms, five projects that pay for themselves fast, what to check before you connect anything to money, what it costs, and the bolttech case study end to end.
TL;DR
An API integration makes two systems you already use talk to each other automatically, so nobody has to copy data by hand. The five projects that pay back fastest: payment processor to accounting, CRM to your product, shipping labels and tracking, one place to see all your numbers, and single sign-on across your internal tools. Before anything touches money, insist on signed requests, rate limits, and encryption. Cost ranges from about $3,000 for a focused payment connection to $20,000 plus for a full reporting pipeline, with upkeep running 10 to 20 percent of the build cost a year. The bolttech case at the end is mine. 40+ payment providers connected, 99.9 percent uptime, zero critical bugs after launch.
Table of contents
- What an API integration actually is
- The three ways systems connect
- Five integrations that pay for themselves
- What to check before anything touches money
- What it costs, and how long it takes
- Case study: bolttech, 40+ payment providers
- FAQ
- The technical part, for your engineer
What an API integration actually is
An API, application programming interface, is the door two pieces of software use to talk to each other. One system says "I need this piece of information." The other says "here it is." No person in the middle.
Think of it as a restaurant order. You tell the waiter what you want. The waiter tells the kitchen. The kitchen sends back a plate. You never walk into the kitchen yourself, and the kitchen never guesses what you meant. That exchange is the whole idea.
Why this matters to your business
Without integrations, your information lives in silos. Customer details in one tool. Payments in another. Support tickets in a third. Getting one clear picture of a single customer means someone opening five tabs and piecing it together by hand. That person is your bottleneck, and their time is a cost your P&L does not show as a line item, but pays anyway.
With integrations, a signup creates the CRM record on its own. A purchase updates your accounting and sends the receipt. A shipment status shows up on a customer's dashboard without anyone touching a keyboard.
I built the Imohub property portal on exactly this principle. Indexing 120,000 plus listings by hand would never have worked. The integrations were the product. Full story: Imohub real estate portal case study.
The three ways systems connect
You do not need to know the engineering behind these to make a good decision. You need to know what each one is for.
The everyday connection (REST). This is the default choice for almost every integration, and it is what your accountant's software, your CRM, and your payment processor already speak. It is simple, every developer knows it, and it works for the vast majority of business connections.
The custom-shaped connection (GraphQL). Used when an app needs to pull many different pieces of related data in one trip, and different screens need different shapes of the same data. Worth it only once you have real complexity to manage. Most small and mid-size businesses never need this one.
The system that tells you first (webhooks). Instead of your tool constantly asking "has anything changed yet?", the other system pushes you a message the moment something happens. A payment clears. A shipment ships. A deal closes. This is how you get real-time updates without anyone checking a screen every five minutes.
The detail behind each of these, with code samples for your developer, is in the engineer section near the end of this guide.
Five integrations that pay for themselves
1. Payment processor to accounting
Before: payments sit in the processor. Accounting sits somewhere else. Someone reconciles by hand on Mondays. A refund takes two days to actually show up anywhere useful.
After: the charge clears, your books update within seconds, the receipt goes out on its own, and reconciliation happens continuously instead of once a week.
What this is actually worth: roughly 5 hours a week of manual reconciliation, plus a customer trust you lose every time a refund is slow. At a $150 hourly labor cost, that is about $39,000 a year sitting in a spreadsheet nobody wanted to build. A typical connection like this runs $3,000 to $8,000 and pays for itself in 10 to 12 weeks.
The one thing I will not skip on this one: every message from the payment processor has to carry proof it actually came from the processor. Skip that check and anyone who finds your web address can fake a payment event. If Stripe is the connection you need next, the Stripe integration services page covers what is included and how long it takes.
2. CRM and product, kept in sync
Before: the CRM has contact details and deal history. Your product has usage data. Sales is flying blind into renewals. Support has no idea who is a good customer and who is barely hanging on.
After: a signup creates a CRM record automatically. Product usage shows up on that customer's timeline. A deal moving to "closed" or "at risk" fires a message on its own. Sales calls the right people. Support knows who they are talking to.
This is one of the highest-return connections I build. Your team stops doing data entry, support stops asking "is this person even paying us?", and warning signs show up before a customer actually leaves. Typical cost: $5,000 to $15,000 depending on how much data moves.
3. Shipping labels and tracking
If someone on your team is typing addresses from your store into a shipping company's website by hand, you have already paid for this integration in lost weekends.
Cost to build: $4,000 to $10,000. Per-label fees do not change. What you get back is your operations person's afternoon, and a customer who gets a tracking number the minute they order instead of three days later.
4. One dashboard for your numbers
Your product, your website, your payment processor, your CRM, and your support tool each hold a piece of the answer to "which marketing channel actually brings us the best customers?" If those pieces live in five places, you cannot answer that question. You can guess. Guessing is expensive.
The upfront cost is not the connections themselves, it is agreeing on what to call things before you build. Skip that step and you rebuild this project twice.
Build cost: $8,000 to $20,000. Ongoing: $500 to $5,000 a month depending on how much data moves through it.
5. One login for every internal tool
Ten tools. Ten passwords. Someone leaves the company and IT has to remember to lock them out of all ten. Your compliance person hates this. Your auditor hates it more.
A single sign-on setup collapses that into one login. Cost to wire up the first time: $3,000 to $10,000, plus a per-seat fee for the login provider. Worth it the moment your headcount passes about 10, and necessary well before any compliance review.
What to check before anything touches money
Every integration opens a door. Here is what has to be true before that door opens near anything valuable.
- Every connection proves who it is. Passwords and keys get rotated regularly and never sit in a document anyone can stumble on.
- Every connection has a speed limit. Without one, a bug in someone else's system can flood yours and take it down, and your hosting bill goes up while it happens.
- Everything is locked in transit and at rest. No plain, unlocked connections, not even for testing.
- Every incoming message proves where it came from. A message claiming to be from your payment processor has to actually be checked, not trusted on sight.
- Every access is logged. Who called what, when, and what came back. Not the data itself, the access pattern. When something goes wrong, this log is what tells you whether a customer's information was actually exposed, instead of guessing in a room full of worried people.
The full checklist, with the exact code your engineer should run for each of these, is in the engineer section below.
What it costs, and how long it takes
| Connection | How complex | Cost to build | Timeline | Upkeep |
|---|---|---|---|---|
| Payment processor | Low | $3,000-$8,000 | 2-4 weeks | $100-$300/mo |
| CRM sync | Medium | $5,000-$15,000 | 4-8 weeks | $500-$1,000/mo |
| Shipping | Low-Medium | $4,000-$10,000 | 2-4 weeks | $200-$500/mo |
| Reporting dashboard | High | $8,000-$20,000 | 6-12 weeks | $1,000-$3,000/mo |
| Single sign-on | Medium | $3,000-$10,000 | 2-6 weeks | $500/mo (licenses) |
What drives the range: how good the other company's documentation is, how fast their support responds, and whether the team has done this exact connection before. A worked example: 5 hours a week of payment reconciliation at $150 an hour is $750 a week, or $39,000 a year. A $6,000 connection pays that back in about 8 weeks and keeps paying after that.
For the fuller picture of how I price ongoing work like this, see the custom web applications service page and the fractional CTO service page.
Case study: bolttech, 40+ payment providers
bolttech is a $1B+ fintech backed by Tokio Marine and MetLife Next Gen Ventures. From January 2020 to April 2021, I led the Payment Service: one system in front of 40+ payment providers across Asia and Europe.
Before: each region had its own payment setup. Adding a new market took weeks, because every provider meant a small rebuild instead of a configuration change. Reconciliation ran on inconsistent data. Errors were handled differently everywhere.
After: one Payment Service absorbed every provider's quirks behind a single, clean connection. Retries and duplicate-message protection ran automatically. Reconciliation ran on one normalized stream. Adding a new provider became a configuration change with tests, not a rebuild.
The outcome:
- 40+ payment providers connected under one system
- 99.9 percent uptime
- 15+ new markets launched
- Zero critical bugs after launch
Full write-up: bolttech: 40+ payment integrations. I applied the same pattern at Cuez to cut API response time from 3 seconds to 300 milliseconds and infrastructure cost by about 40 percent. Read Cuez: API optimization from 3s to 300ms.
FAQ
Do I need this if I am a small company?
Yes, and often more than a large one. Manual data entry costs you more when you have fewer people to do it. Even a single connection between your payment tool and your accounting software eliminates hours of busywork that only gets worse as you grow.
How long does a connection take to build?
Simple ones, payment and shipping, land in 2 to 4 weeks. Complex ones, reporting pipelines and deep CRM syncs, take 6 to 12 weeks. The other company's documentation and support speed drive most of the difference.
What if the other company changes how their system works?
Most providers keep older versions running for 12 months or more. Budget 10 to 20 percent of the original build cost per year for upkeep. Some of that pays for updates. Most of it pays for small fixes that stop a bigger rebuild later.
Can I connect systems without hiring an engineer?
For simple cases, a hosted checkout page, or a no-code connector between two everyday tools, yes. For anything custom, or anything touching real money or personal data, hire someone who has done it before.
What happens if a connected system goes down?
A well-built connection degrades gracefully: it queues the request, retries, logs the failure, and alerts someone. The worst setups assume the other system will never fail. It will, eventually.
Should I build my own API for others to use?
Only if outside customers or partners need to connect to you. If the connection is purely internal, the better spend is connecting the tools you already pay for.
The technical part, for your engineer
Everything below is for the person who will actually build this. It restates the guide above with the protocol names, code samples, and edge cases a developer needs.
REST, GraphQL, and webhooks in practice
REST runs on plain HTTP verbs (GET, POST, PUT, DELETE) against endpoints, returning JSON.
GET /api/customers/123
→ { "id": 123, "name": "Acme Corp", "email": "..." }
POST /api/orders
→ { "order_id": "ord_456", "status": "pending" }
Every language has a client, every engineer can read it, every monitoring tool understands it. Stripe, Twilio, GitHub, and AWS all default to REST. The failure modes are over-fetching and N+1 patterns: one call for a list of IDs, then one call per ID for details.
GraphQL lets the client describe the exact shape of the response it wants:
query {
customer(id: 123) {
name
email
orders {
id
amount
status
}
}
}
One round trip, nothing extra, strongly typed, real-time subscriptions built into the spec. Reference: GraphQL specification. The cost is more setup, harder caching, and thinner tooling. Reach for it only with real data-relationship complexity and multiple client shapes to serve, the way Shopify and GitHub do.
Webhooks invert the polling model. The other system pushes an HTTP POST the moment something happens:
Stripe webhook → POST https://yoursite.com/webhooks/stripe
Body: { "event": "charge.succeeded", "amount": 4999, ... }
Requires a public endpoint, signature verification, and idempotency handling for duplicate delivery. Skip any of the three and webhooks become a forged-request vector.
Security floor, in code
Verify every webhook signature. Do not trust the payload on sight:
import hmac, hashlib
expected = hmac.new(
webhook_secret.encode(),
request.body,
hashlib.sha256,
).hexdigest()
if not hmac.compare_digest(signature, expected):
return "Unauthorized", 401
OAuth 2.0 for user-facing flows, scoped API keys with 90-day rotation for service-to-service calls, mutual TLS for regulated finance and health. Rate limit every API you publish and respect the rate limits on every API you consume; see the OWASP API Security Top 10. TLS everywhere in transit, KMS-managed encryption at rest, never a homegrown scheme.
Protocols you will meet beyond the big three
OAuth 2.0 and OpenID Connect. RFC 6749 is the canonical spec for delegated access.
SAML. Older, heavier enterprise SSO. Still required by large B2B security teams.
WebSockets. Bidirectional, persistent, full-duplex. Chat, live dashboards, collaborative editing.
Server-sent events. One-way push over plain HTTP. Cheaper than WebSockets when updates only flow one direction.
gRPC. Binary, HTTP/2, typed contracts. Strong fit for internal service-to-service traffic.
Message queues (Kafka, RabbitMQ, SQS). How production integrations move at scale. The bolttech Payment Service ran on queues for retries and idempotency past a handful of high-volume providers.
Versioning and the moving target
Version every API from day one (/v1/). Subscribe to every provider's deprecation notices and triage monthly. Pin to a specific version, never "latest." Test contract changes against the new version in staging before flipping production. Budget 10 to 20 percent of the original build cost per year, split between upgrades, provider outages, and the small fixes that prevent a bigger rewrite.
Reference architecture: an events pipeline
Product → Event API ↘
Website → Event API ↘
CRM → Event API → Warehouse → Dashboards
Payment → Event API ↗
Support → Event API ↗
Segment, Snowflake, BigQuery, or a custom event collector all work. The hard part is agreeing on event names and properties before the first pipe is built.
I have built these connections across payment processors (Stripe, Braintree, Adyen, and the 40+ at bolttech), CRMs (Salesforce, HubSpot), shipping providers, and analytics platforms. If you want a hand prioritizing the roadmap, get a quote in 60s.
Related reading
Services I offer
- Custom web applications: senior engineering on subscription
- Fractional CTO: technical leadership without a full-time hire
Case studies
- bolttech: 40+ payment integrations: payment orchestration at a $1B+ fintech
- Cuez: API 10x faster: 3s to 300ms
- GigEasy MVP in 3 weeks: what a senior solo engineer can ship for a Barclays/Bain-backed fintech
Related guides