02 / WHAT AN API ACTUALLY DOES

An API is a contract between software systems.

At a practical level, an API defines how one application can request information or ask another application to perform an operation. The contract normally specifies endpoints, authentication, request formats, response formats, errors and expected behavior.

CRM
   │
   │ API REQUEST
   ▼
INTEGRATION SERVICE
   │
   ├────────► ACCOUNTING
   │
   ├────────► INTERNAL PORTAL
   │
   └────────► NOTIFICATION SERVICE

The important architectural idea is that employees no longer need to act as the integration layer. Software communicates with software.

03 / MANUAL INTEGRATION

Humans frequently become the API before an API exists.

Consider a customer order that arrives through one system. An employee copies the customer's name into a spreadsheet, enters the order into another platform, creates an invoice, saves a PDF and emails someone else to continue the workflow.

CUSTOMER REQUEST
       ↓
EMPLOYEE
       ↓
COPY DATA
       ↓
SPREADSHEET
       ↓
COPY AGAIN
       ↓
ACCOUNTING SYSTEM
       ↓
CREATE PDF
       ↓
SEND EMAIL
       ↓
UPDATE INTERNAL SYSTEM

This workflow may function at low volume, but every additional manual transition creates opportunities for delay, duplicate entry, inconsistent data and missing updates.

We discussed this broader transition from spreadsheets and manual workflows in Engineering 001: When Excel Stops Scaling.

04 / POINT-TO-POINT INTEGRATION

The simplest integration connects System A directly to System B.

SYSTEM A ───────── API ─────────► SYSTEM B

Point-to-point integration can be completely reasonable when only two systems need to communicate and the workflow is simple.

Problems begin when every application creates direct connections to every other application.

CRM ───────────────► ACCOUNTING
 │  ╲                    ▲
 │   ╲                   │
 ▼    ╲                  │
PORTAL ───────────────► STORAGE
 │                       ▲
 └──────────────► NOTIFICATIONS

As the number of systems increases, point-to-point integrations can create tightly coupled architecture where changes in one application unexpectedly affect several others.

05 / INTEGRATION LAYER

An integration layer can separate business systems from each other.

Instead of teaching every application how every other application works, an organization can introduce an integration service, middleware layer or dedicated backend responsible for communication.

                 ┌──────────── CRM
                 │
                 ├──────────── ACCOUNTING
                 │
INTEGRATION  ────┼──────────── INTERNAL PORTAL
LAYER            │
                 ├──────────── STORAGE
                 │
                 ├──────────── PAYMENTS
                 │
                 └──────────── NOTIFICATIONS

This layer can normalize data, enforce authentication, implement retries, record audit events and isolate vendor-specific behavior.

06 / REST APIs

REST remains a common model for business integrations.

REST APIs commonly expose resources over HTTP and use methods such as GET, POST, PUT, PATCH and DELETE to communicate operations.

GET    /customers/4821
POST   /orders
PATCH  /orders/928/status
DELETE /sessions/183

HTTP RESPONSE
200 OK
201 Created
400 Bad Request
401 Unauthorized
403 Forbidden
404 Not Found
409 Conflict
429 Too Many Requests
500 Internal Server Error

Correct HTTP semantics matter because integrations need predictable behavior. An API that returns a successful 200 response for every situation forces consumers to invent additional rules for determining whether an operation actually succeeded.

07 / SYNCHRONOUS COMMUNICATION

Sometimes the caller needs an answer immediately.

In synchronous communication, one system sends a request and waits for the response before continuing.

PORTAL
   │
   │ POST /customer
   ▼
CRM
   │
   │ 201 CREATED
   ▼
PORTAL CONTINUES

This model is useful when the next business action depends directly on the response. But it also means the caller becomes sensitive to latency and availability of the downstream service.

08 / ASYNCHRONOUS COMMUNICATION

Not every operation should block the user.

Sending notifications, generating reports, processing documents, synchronizing external systems or running AI analysis may take longer than a normal interactive request should remain open.

USER ACTION
     ↓
APPLICATION
     ↓
QUEUE / EVENT
     ↓
BACKGROUND WORKER
     ↓
EXTERNAL API
     ↓
RESULT STORED
     ↓
USER NOTIFIED

Asynchronous processing can improve resilience because temporary downstream failures do not necessarily need to become immediate user-facing failures.

09 / WEBHOOKS

Webhooks allow another system to tell you when something changed.

Without a webhook, an application may repeatedly ask an external service whether new information exists. This is polling.

POLLING

YOUR SYSTEM ──► ANYTHING NEW?
YOUR SYSTEM ──► ANYTHING NEW?
YOUR SYSTEM ──► ANYTHING NEW?


WEBHOOK

EXTERNAL SYSTEM
       │
       │ EVENT OCCURS
       ▼
POST /webhooks/payment-completed
       │
       ▼
YOUR SYSTEM

Webhooks are especially useful for payments, delivery status, document processing, messaging, identity events and many other workflows where the consumer needs to react to an external change.

10 / WEBHOOK SECURITY

A webhook endpoint is still an internet-facing API endpoint.

Receiving a POST request does not prove that the request originated from the expected provider. Production webhook implementations often require signature verification, timestamp validation, replay protection and strict payload validation.

11 / POLLING

Polling is not automatically bad architecture.

Some providers do not support webhooks. Some integrations need periodic reconciliation even when webhooks exist. In those cases, polling can be appropriate if frequency, rate limits, pagination and failure recovery are designed deliberately.

A useful architecture may use webhooks for fast notification and a scheduled reconciliation process to detect anything that was missed.

12 / AUTHENTICATION

Systems need identities just as users do.

API authentication answers a fundamental question: which application, service or user is making this request?

Depending on the provider and risk model, integrations may use API keys, OAuth access tokens, signed requests, service accounts, certificates or other credentials.

CLIENT
  │
  │ CREDENTIAL / TOKEN
  ▼
API GATEWAY
  │
  ├── AUTHENTICATE
  ├── AUTHORIZE
  ├── RATE LIMIT
  ├── VALIDATE
  │
  ▼
APPLICATION

13 / API KEYS

API keys identify access, but they are not a complete security model.

API keys are convenient for server-to-server integrations, but they should be treated as secrets. They should not be embedded in public frontend JavaScript, committed into source repositories or placed into URLs where infrastructure logs may capture them.

For high-value operations, authorization needs to consider what the authenticated identity is actually permitted to do.

14 / OAUTH 2.0

Delegated access requires a different model.

OAuth is commonly used when an application needs permission to access another service on behalf of a user or organization without receiving that user's password.

USER
 │
 ▼
YOUR APPLICATION
 │
 │ AUTHORIZATION
 ▼
IDENTITY / AUTHORIZATION SERVER
 │
 │ ACCESS TOKEN
 ▼
YOUR APPLICATION
 │
 │ AUTHORIZED API REQUEST
 ▼
RESOURCE API

Token scope, expiration, rotation and secure storage become part of the integration architecture.

15 / AUTHORIZATION

Authentication tells you who. Authorization tells you what.

A service may be correctly authenticated and still have no reason to access every customer, modify financial records or execute administrative operations.

Least-privilege access reduces the impact of credential compromise and accidental misuse.

This becomes particularly important in internal portals with multiple employee roles. See Engineering 003: When Does a Business Need an Internal Portal?.

16 / IDEMPOTENCY

What happens if the same request arrives twice?

Distributed systems experience timeouts and uncertain outcomes. A client may send a request successfully but lose the response. It then faces a difficult question: should it retry?

CREATE PAYMENT
      │
      ▼
SERVER PROCESSES PAYMENT
      │
      X  RESPONSE LOST
      │
CLIENT TIMES OUT
      │
      ▼
RETRY?

WITHOUT IDEMPOTENCY:
POSSIBLE DUPLICATE OPERATION

WITH IDEMPOTENCY:
SAME LOGICAL REQUEST → SAME EFFECT

HTTP itself defines certain methods as idempotent, but business operations frequently need additional application-level protection. Payment creation, order creation and other POST-style workflows may use an idempotency key or equivalent transaction identifier.

17 / RETRIES

Retrying everything immediately can make an outage worse.

Temporary failures are normal in distributed systems. Networks fail, services restart, providers throttle traffic and dependencies become unavailable.

A resilient integration distinguishes between errors that may succeed later and errors that require human or application intervention.

REQUEST
  │
  ▼
TEMPORARY FAILURE
  │
  ▼
WAIT
  │
  ▼
RETRY
  │
  ▼
LONGER WAIT
  │
  ▼
RETRY
  │
  ├── SUCCESS → CONTINUE
  │
  └── FAILURE → DEAD LETTER / ALERT

18 / EXPONENTIAL BACKOFF

Retries need spacing and limits.

Exponential backoff increases the delay between repeated attempts. Jitter can further reduce the risk that thousands of clients retry at exactly the same moment after an outage.

19 / RATE LIMITS

External APIs are not unlimited infrastructure.

Providers frequently limit request volume to protect capacity and enforce service plans. Integrations therefore need to understand throttling responses and avoid treating rate limits as mysterious application failures.

10,000 JOBS
    │
    ▼
WORK QUEUE
    │
    ▼
RATE CONTROLLER
    │
    ├──► API
    ├──► API
    ├──► API
    │
    └── WAIT WHEN THROTTLED

20 / QUEUES

A queue can absorb differences in system speed.

Your application may generate work faster than an external provider can accept it. A queue creates a buffer between production and consumption of that work.

Queues are useful for document processing, email delivery, bulk synchronization, AI jobs, imports, exports and other workloads where immediate completion is unnecessary.

21 / DEAD-LETTER QUEUES

Some jobs will continue failing no matter how many times you retry them.

A message may contain invalid data, reference a deleted external record or trigger a provider error that requires manual investigation.

Instead of retrying forever, systems can move repeatedly failing work into a dead-letter queue or equivalent failure store.

NORMAL QUEUE
    │
    ▼
PROCESS
    │
    ├── SUCCESS ─────► COMPLETE
    │
    └── FAILURE
          │
          ▼
        RETRY
          │
          ▼
     MAX ATTEMPTS
          │
          ▼
DEAD-LETTER QUEUE
          │
          ▼
INSPECT / FIX / REPLAY

The important part is not merely storing the failure. Operators need enough context to understand what failed and safely replay it later.

22 / EVENT-DRIVEN ARCHITECTURE

Sometimes systems should publish facts instead of commanding each other.

In event-driven architecture, one system publishes that something happened: an order was created, a payment completed, a document was uploaded or a driver changed status.

Other systems subscribe to the events they care about.

ORDER SERVICE
      │
      │ ORDER_CREATED
      ▼
EVENT BUS
 ├────────► ACCOUNTING
 ├────────► NOTIFICATIONS
 ├────────► ANALYTICS
 └────────► INTERNAL PORTAL

This can reduce direct coupling, but it introduces new concerns: ordering, duplicate delivery, schema evolution, observability and eventual consistency.

23 / EVENTUAL CONSISTENCY

Distributed systems may not agree instantly.

When updates move asynchronously, one system may reflect a change milliseconds or seconds before another system receives it.

That is not automatically a defect. The question is whether the business workflow can tolerate temporary inconsistency.

24 / DATA MAPPING

Two systems rarely describe the same business object in exactly the same way.

One CRM may call a field customer_id. Another platform may use accountNumber. An internal system may identify the same entity with a UUID.

Integration therefore requires a deliberate mapping layer.

CRM
customer_id
first_name
last_name
phone

       ↓ MAP ↓

INTERNAL PORTAL
customerId
displayName
phoneNumber

       ↓ MAP ↓

ACCOUNTING
accountRef
legalName
contactPhone

Mapping should also define how null values, formats, units, currencies, time zones and enumerations are transformed.

25 / CANONICAL DATA MODEL

A shared internal representation can reduce repeated translation.

When many external systems use different schemas, an integration layer can map each provider into a canonical internal model.

This avoids teaching every downstream service the proprietary schema of every vendor.

VENDOR A ─┐
          │
VENDOR B ─┼──► CANONICAL MODEL ───► BUSINESS LOGIC
          │
VENDOR C ─┘

26 / SCHEMA EVOLUTION

APIs change. Integrations have to survive those changes.

Fields are added. Old fields are deprecated. Enumerations gain new values. Payloads become more complex.

Consumers should avoid assuming that every payload will remain permanently identical to today's example.

Defensive parsing, explicit contracts and compatibility testing can reduce breakage as APIs evolve.

27 / API VERSIONING

Breaking changes need a migration strategy.

APIs may expose versions in URLs, headers or negotiated contracts. The exact mechanism matters less than communicating compatibility expectations clearly.

/api/v1/customers
/api/v2/customers

OLD CLIENT ─────► V1
NEW CLIENT ─────► V2

MIGRATE
VALIDATE
DEPRECATE
REMOVE

Removing an old version before consumers migrate can turn an API deployment into a multi-system outage.

28 / PAGINATION

“Give me every record” stops working surprisingly quickly.

Large datasets should normally be retrieved in pages or through cursor-based iteration rather than one enormous response.

Integrations should understand continuation tokens, page boundaries, ordering guarantees and how records changing during synchronization affect the result.

29 / BULK SYNCHRONIZATION

Initial imports and daily synchronization are different workloads.

Connecting a new system may require importing years of historical records. After the initial migration, only incremental changes may need synchronization.

INITIAL SYNC
1,000,000 RECORDS
      ↓
BATCH / PAGINATION
      ↓
VALIDATION
      ↓
CHECKPOINT


ONGOING SYNC
ONLY CHANGES
      ↓
WEBHOOK / EVENT / POLL
      ↓
UPDATE

30 / CACHING

Not every request needs to reach the provider every time.

Frequently requested data that changes infrequently may be cached to improve responsiveness and reduce API consumption.

But caching creates another question: how stale is acceptable?

Cache lifetime should follow business requirements. A product description may tolerate delay. A payment status may not.

31 / TIMEOUTS

Every external request needs a time boundary.

Without explicit timeouts, one unavailable dependency can consume resources indefinitely and cause failures to spread through the application.

USER REQUEST
    │
    ▼
YOUR SERVICE
    │
    ▼
EXTERNAL API
    │
    X NO RESPONSE

WITHOUT TIMEOUT:
WAIT...

WITH TIMEOUT:
FAIL CONTROLLED
RETRY / FALLBACK / QUEUE

32 / CIRCUIT BREAKERS

If a dependency is clearly failing, stop hammering it.

A circuit breaker temporarily stops requests to an unhealthy downstream service after repeated failures.

This allows the provider time to recover and prevents every user request from waiting for the same predictable failure.

CLOSED
REQUESTS FLOW
   │
   ▼
FAILURES EXCEED THRESHOLD
   │
   ▼
OPEN
REQUESTS FAIL FAST
   │
   ▼
WAIT
   │
   ▼
HALF OPEN
TEST REQUEST
   │
   ├── SUCCESS → CLOSED
   └── FAILURE → OPEN

33 / THIRD-PARTY OUTAGES

Your application can be healthy while an integration is not.

A payment provider, CRM, mapping service or document API may be temporarily unavailable even while your own infrastructure works normally.

Good user experience distinguishes between internal failure and delayed external processing.

“We received your request and will synchronize it when the provider becomes available” is very different from losing the request.

34 / RECONCILIATION

Even event-driven integrations need a way to verify reality.

Webhooks can be missed. Queues can contain poison messages. Credentials expire. Providers can experience incidents.

Reconciliation compares expected state with actual external state and identifies differences.

INTERNAL RECORDS
       │
       ├──── COMPARE ────┐
       │                 │
       ▼                 ▼
EXPECTED STATE      PROVIDER STATE
       │                 │
       └──────┬──────────┘
              ▼
        DIFFERENCES?
          │      │
         NO     YES
          │      │
       COMPLETE  REPAIR / ALERT

35 / OBSERVABILITY

“The integration failed” is not enough information.

Production systems need logs, metrics and alerts that reveal where requests fail, how often retries happen, how long providers take to respond and whether synchronization queues are growing.

Useful metrics may include:

• request volume;
• success and error rates;
• provider latency;
• retry count;
• rate-limit events;
• queue depth;
• dead-letter volume;
• webhook verification failures;
• synchronization delay;
• authentication failures.

36 / CORRELATION IDS

One business operation may cross five different services.

A correlation ID allows logs from multiple components to be associated with the same logical transaction.

REQUEST ID: req_82A91

WEB APP
  ↓ req_82A91
API
  ↓ req_82A91
QUEUE
  ↓ req_82A91
WORKER
  ↓ req_82A91
ACCOUNTING PROVIDER

ONE BUSINESS ACTION
ONE TRACEABLE IDENTIFIER

37 / AUDIT LOGS

Operational logs and audit logs serve different purposes.

Technical logs help engineers understand application behavior. Audit records help answer business questions such as who initiated an action, what changed and when it happened.

For sensitive workflows, both may be necessary.

38 / INPUT VALIDATION

External data is untrusted data.

An authenticated provider can still send malformed, unexpected or semantically invalid data.

Integrations should validate data types, lengths, allowed values, identifiers and business constraints before using external payloads to modify internal state.

39 / OUTPUT CONTROL

Do not send more information than the integration needs.

APIs should expose the minimum information required for the workflow. Sensitive internal fields should not become external simply because they exist in the database.

This principle becomes particularly important with personally identifiable information, financial records and employee data.

40 / SECRETS MANAGEMENT

Credentials are infrastructure, not source code.

API keys, OAuth client secrets, private keys and database credentials should be stored through appropriate secret-management mechanisms and separated from publicly distributed application code.

Rotation procedures also matter. A secret that cannot be rotated safely becomes a long-term operational liability.

41 / API GATEWAYS

A gateway can centralize cross-cutting API concerns.

Depending on architecture, an API gateway can provide routing, authentication, rate limiting, request validation, metrics and other controls before traffic reaches application services.

CLIENTS
   │
   ▼
API GATEWAY
 ├── AUTH
 ├── RATE LIMIT
 ├── ROUTING
 ├── LOGGING
 └── POLICY
   │
   ├────────► SERVICE A
   ├────────► SERVICE B
   └────────► SERVICE C

A gateway is useful infrastructure, but it cannot compensate for poorly designed authorization or inconsistent business rules inside the services themselves.

42 / INTEGRATION TESTING

Mock responses are useful. Real provider behavior is still different.

Unit tests can verify transformation logic. Integration tests can validate contracts. Sandbox environments can test authentication and provider-specific behavior.

Production integration still needs monitoring because real datasets, throttling and outages can reveal behaviors that test environments do not reproduce.

43 / SANDBOX ENVIRONMENTS

Use provider test environments when they exist.

Payment providers, identity platforms and enterprise APIs often provide sandbox or test tenants.

These environments reduce the risk of accidentally creating real charges, customers, notifications or production data while integration logic is under development.

44 / CONTRACT TESTING

An API can be online and still break your integration.

Contract testing focuses on the structure and behavior one system expects from another.

If a provider changes an important response field or your internal API changes a required request property, contract tests can identify the incompatibility before production deployment.

45 / LEGACY SYSTEM INTEGRATION

Old software can still participate in modern API architecture.

Legacy systems frequently lack modern APIs. An adapter can expose a controlled boundary around an older database, service or application.

LEGACY SYSTEM
      │
      ▼
ADAPTER / ANTI-CORRUPTION LAYER
      │
      ▼
MODERN API
      │
      ├──► INTERNAL PORTAL
      ├──► MOBILE APP
      ├──► AUTOMATION
      └──► AI SERVICES

This approach connects directly with Engineering 004: Legacy Software Modernization.

46 / ACCOUNTING INTEGRATION

Financial integrations require especially clear ownership.

An internal portal may calculate operational values while accounting software remains authoritative for invoices, payments and financial reporting.

OPERATIONS
    │
    ▼
INTERNAL PORTAL
    │
    │ APPROVED FINANCIAL EVENT
    ▼
ACCOUNTING API
    │
    ▼
INVOICE / PAYMENT RECORD
    │
    ▼
REFERENCE STORED INTERNALLY

The architecture should define which system owns the financial truth and how corrections flow in both directions.

47 / CRM INTEGRATION

A CRM and an operational portal can own different parts of the customer relationship.

CRM may remain authoritative for leads, opportunities and sales activity, while a custom operational system manages fulfillment after a deal becomes active.

Integration prevents sales and operations from maintaining independent versions of customer information.

48 / DOCUMENT INTEGRATION

Files need metadata and lifecycle, not only upload buttons.

A storage provider may hold binary files while your internal system stores document type, owner, expiration, workflow state and access permissions.

BUSINESS RECORD
      │
      ├── DOCUMENT TYPE
      ├── STATUS
      ├── OWNER
      ├── EXPIRATION
      │
      ▼
STORAGE API
      │
      ▼
FILE OBJECT

49 / TRANSPORTATION INTEGRATION

Transportation workflows often depend on many systems at once.

Dispatch, drivers, vehicle records, documents, settlements, claims, accounting and customer communication may all require data exchange.

M&N Soft's Driver Portal case study demonstrates how specialized transportation workflows can be centralized while still integrating with external services.

We also build custom transportation software.

50 / AI AGENTS & APIs

AI agents become operational when they can call tools.

A language model can analyze text by itself, but an AI agent becomes much more operationally significant when it can read customer data, create requests, search documents or invoke business APIs.

USER
  │
  ▼
AI AGENT
  │
  ├──► SEARCH API
  ├──► CRM API
  ├──► DOCUMENT API
  └──► INTERNAL ACTION API
            │
            ▼
      BUSINESS SYSTEM

This also creates a major security requirement: the agent should not gain broader permissions than the workflow requires.

Tool access, human approval and auditability become part of AI architecture rather than optional features.

Learn more about AI integration for business.

51 / HUMAN APPROVAL

Automation does not require removing humans from every decision.

Low-risk actions may be executed automatically while high-impact operations require approval.

AUTOMATION / AI
      │
      ▼
PROPOSE ACTION
      │
      ├── LOW RISK ─────► EXECUTE
      │
      └── HIGH RISK
             │
             ▼
        HUMAN REVIEW
             │
        ┌────┴────┐
        ▼         ▼
      APPROVE   REJECT

52 / BUILD VS BUY

Should you build integration infrastructure or use an automation platform?

Products such as integration platforms and automation tools can be excellent when workflows fit their supported connectors and operational requirements.

Custom integration becomes more valuable when business logic is proprietary, security requirements are specialized, data volume is significant or workflows need deeper control than a generic connector provides.

Use the simplest integration architecture that reliably satisfies the business requirement.

53 / COMMON FAILURE MODES

Ten ways API integrations become operational problems.

• No timeout on external requests.
• Infinite retries.
• No idempotency for duplicate-sensitive operations.
• Secrets embedded in application code.
• No verification of webhook signatures.
• No reconciliation after missed events.
• No visibility into queue backlog.
• One service owns data but another silently modifies it.
• Breaking schema changes without versioning.
• No operational process for replaying failed jobs.

54 / DECISION MATRIX

Which communication pattern fits which requirement?

55 / INTEGRATION CHECKLIST

Before connecting two business systems, answer these questions.

• Which system owns each type of data?
• Is communication synchronous or asynchronous?
• How is the caller authenticated?
• What is the minimum required authorization?
• What happens if a request is duplicated?
• Which errors should be retried?
• What is the timeout?
• What rate limits exist?
• How are failed jobs recovered?
• How are webhooks verified?
• How is synchronization reconciled?
• How will schema changes be handled?
• Which metrics should trigger alerts?
• How are secrets rotated?
• How will the integration be tested?

56 / RELATED M&N SOFT ENGINEERING

API integration is one layer of a larger business system.

Engineering 001 — When Excel Stops Scaling →

Engineering 002 — Custom Software Cost in the USA →

Engineering 003 — When Does a Business Need an Internal Portal? →

Engineering 004 — Legacy Software Modernization →

Custom Software Development →

Business Process Automation →

57 / FAQ

Frequently asked questions about API integration.

What is API integration?

API integration is the connection of independent software systems through defined application interfaces so they can exchange data or trigger operations automatically.

What is the difference between an API and a webhook?

An API request is normally initiated by the consumer. A webhook is typically initiated by the provider when an event occurs.

Are REST APIs secure?

REST itself does not make an API secure or insecure. Security depends on transport protection, authentication, authorization, validation, secret handling, access control and application design.

Should an integration retry failed requests?

Some failures are appropriate to retry. Others are not. Retry behavior should depend on request semantics, idempotency and provider guidance.

What is an idempotency key?

It is an identifier that allows a server to recognize repeated attempts of the same logical operation and avoid producing duplicate effects.

When should we use a message queue?

Queues are useful when work can happen asynchronously, when processing rates differ or when temporary downstream outages should not lose work.

Should every system connect directly to every other system?

Not necessarily. As ecosystems grow, a dedicated integration layer can reduce coupling and centralize common reliability concerns.

Can an old legacy application have a modern API?

Often yes. An adapter or abstraction layer can expose selected legacy capabilities while protecting new applications from legacy implementation details.

Can AI agents safely call business APIs?

They can, but tool access should use strict authorization, validation, auditability and human approval where consequences are significant.

How much does API integration cost?

Cost depends on the number of systems, API quality, authentication, data complexity, workflow rules, reliability requirements and testing. For broader market context, see Engineering 002 — Custom Software Cost in the USA.

58 / PRIMARY SOURCES & TECHNICAL REFERENCES

Standards and security guidance relevant to API architecture.

The following primary technical resources provide additional context for HTTP semantics, API security, OAuth and secure software design.

IETF / RFC Editor — RFC 9110: HTTP Semantics ↗

IETF / RFC Editor — RFC 6749: OAuth 2.0 Authorization Framework ↗

OWASP — REST Security Cheat Sheet ↗

OWASP — API Security Project ↗

NIST SP 800-228 — Guidelines for API Protection ↗

NIST SP 800-218 — Secure Software Development Framework ↗

NIST SP 800-207 — Zero Trust Architecture ↗

59 / M&N SOFT PERSPECTIVE

Good integration removes invisible manual work.

The goal of API integration is not to maximize the number of connected systems.

The goal is to create a dependable flow of information so employees do not spend their time moving the same data manually between software products.

Depending on the workflow, that may involve a simple REST connection, a webhook, a queue, an integration service, a custom internal portal or a larger business automation architecture.

An integration is successful when the business can depend on it even when networks, providers and individual requests fail.

DISCUSS AN INTEGRATION

Need your business systems to actually work together?

M&N Soft develops API integrations, internal business portals, workflow automation, transportation software, AI integrations and custom software around real operational processes.

We can begin by mapping the systems you already use, identifying the source of truth for each type of data and determining where automation can remove manual work.