API integration services that keep your systems working from the same records

Who are API integration services for?

Many established businesses run on systems bought at different times from different vendors: a CRM for sales, an accounting package, an operations or dispatch system, and spreadsheets filling the gaps between them. Wherever someone types a record from one system into another, errors and delays can follow. The integrations we build look different at each size of business:

• Established local businesses: one location or service area, a handful of systems and a team that retypes orders, customers or invoices between them. The first integration goes where most of that typing happens.
• Multi-location and regional businesses: offices that may run their own tools, or the same system set up differently in each. The integration brings their records into one shape the business can report from.
• National businesses: more systems, larger volumes, and IT and security teams with rules of their own. Rate limits, audit trails and change control become part of the work, alongside the connections.

Formed in 2023, Midnite Systems builds integrations for businesses across the US, and we do the work from our office in Valencia. If a connector you can switch on, or an automation tool, would do the job, we’ll tell you on the call.

What do API development and integration services include?

IBM describes API integration as linking a business’s applications, systems and workflows through their APIs, so data and services can pass between them. The work has two halves. Integration connects the APIs your systems already publish. API development builds a new API when one of your own systems has none, or when the one it has can’t do what the integration needs. API development and integration services cover both, and an API we would build for one of your systems comes with:

• Documentation: each endpoint, field and error written down, so another developer or vendor can work with it.
• Authentication: keys or tokens for each system that calls it, each limited to what that system needs.
• Versions: a version number on the API, so a change doesn’t break the systems already using it.
• Limits: a cap on requests from each caller, answered with the standard 429 Too Many Requests status when it’s passed.
• Logs: a record of each call, who made it and what came back.

Many current CRM, accounting and ERP products publish an API. Where all of yours do, the work is the integration alone: mapping the records, writing the connections and handling what goes wrong.

How should a CRM and an ERP share records?

A CRM is where sales works leads and deals. An ERP is where products, orders, stock and invoices live. Both hold a version of the same customer, and keeping that customer the same in both is much of the integration work. The records the two usually share:

• Customers: created in the CRM when a deal is won, then kept in step with the matching account in the ERP.
• Products and prices: owned by the ERP and sent to the CRM, so quotes go out at current prices.
• Orders: a won deal or an accepted quote becomes an order in the ERP, with the CRM’s reference attached.
• Invoices and balances: sent back from the ERP, so sales can see what a customer owes before calling.

Each shared field needs one owner: a rule for which system wins when both change it. Agreeing who owns what, before any code is written, can save a lot of untangling later. Our pages on custom CRM development, custom ERP development and CRM implementation cover each system on its own.

Do you need custom code or an integration platform?

IBM describes iPaaS, integration platform as a service, as self-service tools in the cloud for connecting applications, systems and data, with prebuilt connectors and templates that reduce the need for custom code. Zapier, Make and n8n work along the same lines for business teams. IBM also notes that point-to-point integrations, written directly in custom code, take substantial setup and upkeep, and are often a poor fit where a business runs hundreds of applications.

To choose, weigh four things:

• An existing connector: if a platform or one of your vendors already connects both systems, start there.
• How unusual the rules are: a flow that copies a record from one system to another is platform work, while one that checks, merges and decides can need code.
• Volume: Zapier bills tasks, Make bills credits and n8n bills executions, so the more often a flow runs, the more of a plan it uses. Price the platform at the volume you expect.
• Who looks after it: a team that can maintain a platform flow itself may not need code at all.

We build flows on Zapier, Make and n8n where they fit, and write code where they don’t. Our page on Zapier, Make and n8n automation covers the platform work, and our guide to Zapier, Make, n8n or custom code walks through the choice.

What do systems integration services cover beyond APIs?

Some systems have no API, or one too thin to use, and systems integration services work with whatever way in a system offers. In rough order of preference:

• File exchange: scheduled exports and imports, such as a CSV file placed on a secure server each night, for systems that can share files but can’t take calls.
• Direct database access: reading from a system’s database, or writing to it where the vendor allows, with care, since a vendor can change its tables without notice.
• Emails and documents: orders, invoices and forms that arrive by email or as PDFs. Reading them usually takes a model, which makes it AI work, and our page on AI integration covers it.
• Screens with no other way in: a script can type into software that offers nothing but a screen, but it can break whenever the screen changes, so it comes last.

Systems integration also covers what sits around the connections: the map of which system owns which records, the monitoring, and a plan for what happens while one system is down.

When are custom API integration services worth it?

IBM’s iPaaS guide says a vendor’s ready-made connector is often the simpler and more cost-effective choice, and that a business can build a custom integration when no ready one exists. Custom API integration services earn their cost in a few situations:

• No connector exists: one of your systems is specialist, old or built in-house, and nothing on the market connects to it.
• The rules are your own: records have to be checked, merged or routed by rules no connector can express.
• Volume or speed: records move in numbers, or at a pace, that a platform’s limits can’t carry.
• Control over the data: you want records to pass only through systems you control, with credentials limited to the integration.

Sometimes neither a connector nor custom code is the answer. When the data is split across tools that each hold part of a record, connecting them adds moving parts without fixing the split. The fix then is the system itself: a custom software build that brings the records together, or a process automation project around the work.

What happens when an integration fails?

Integrations fail now and then: a system goes down, a credential expires, a vendor changes a field, or too many requests arrive at once. For that last case, RFC 6585 defines the 429 Too Many Requests status, which a server can send with a Retry-After header saying how long to wait before trying again. An integration that ignores the signal and keeps calling makes the problem worse. What we would build plans for each case, so a record that fails waits where your team can see it:

• Retries with a pause: a failed call is tried again after a wait, following the Retry-After time when the other system gives one.
• Holds with a reason: a record that still won’t go through is held with a note of what went wrong, for your team to fix or finish by hand.
• Nothing dropped quietly: every record ends either written or held, and the log shows which.
• Health checks: a regular check that each flow is running, with an alert when one stops or falls behind.
• A switch per flow: a way to pause one flow without touching the code or stopping the others.

What do enterprise API integrations need?

Custom enterprise API integration services carry the same parts as any other integration, plus the controls a large company’s IT and security teams ask for:

• Single sign-on: staff reach the integration’s screens and logs through the company’s own sign-in.
• Audit trails: a record of every change to a flow, its settings and its credentials, and who made it.
• Separate environments: test and live kept apart, so a change is tried on test data first.
• A security review: time for the company’s security questionnaire and its reviewers’ questions before anything goes live.
• Change control: changes released on a schedule the IT team approves, with a way back if one goes wrong.

Each adds to the build, and the proposal lists the ones your integration needs.

How do you keep an API integration secure?

OWASP’s API Security Top 10 for 2023 names ten API security risks. Four bear directly on integrations:

• Broken object level authorization: an API that hands over any record whose number a caller asks for. OWASP lists it first, and the fix is checking every request against what that caller may see.
• Broken authentication: weak or mishandled sign-in between systems. Many integrations sign in with tokens, for example under OAuth 2.0, which RFC 6749 describes as a framework that lets an application get limited access to an HTTP service.
• Unrestricted resource consumption: no cap on how much a caller can ask for, so one runaway job can slow a system for everyone.
• Unsafe consumption of APIs: OWASP warns that developers tend to trust data from third-party APIs more than what users type in. An integration should check what it receives before writing it anywhere.

Each connection we would build gets its own credentials, with the narrowest access that lets it do its job, kept out of the code and easy to change.

What does an integration we’ve built look like?

AlvyOne is the operations system that Alvy Logistics and DSI Transportation share, which we built and still run with Alvy. Alvy is owned by our co-founder Noah Alvarez, and DSI is an Alvy company. Its order intake reads emailed orders, checks each address and looks for a duplicate, then creates the order in the dispatch system through that system’s API, holding any order it can’t complete for a dispatcher to finish. Our AI automation page tells how it reads the emails, and the AlvyOne case study covers the whole system.

What we would build for your business starts with the records your team retypes most. A first version would connect one record type in one direction, such as accepted quotes into your accounting system as invoices, with the checks, retries, holds and monitoring described above. Each flow after that reuses the same parts.

What does an integration cost to keep running?

An integration needs looking after for as long as the systems it connects keep changing. Vendors release new API versions and retire old ones, credentials expire, and fields get added or renamed. Hosting, and any platform a flow runs on, have their own costs. Integrations we build run on a monthly plan after launch, with the price set in the proposal. Our page on custom software cost sets out what the market charges to build and run software at each level.

If your team retypes the same records from one system into another, book a 15-minute call. Bring the names of the systems involved, and we’ll tell you whether a connector, a platform flow or custom code fits.