API integrations explained for businesses.

What is an API?

An API — Application Programming Interface — is a technical interface that allows software to communicate with other software according to defined rules.

For example, a CRM may have API endpoints to:

• retrieve a customer
• create a customer
• update a contact person
• retrieve orders
• change a status

An endpoint is simply a specific address or function in the API. One endpoint may be used for customers and another for orders.

The API therefore describes what a system allows other systems to read or do. It does not necessarily describe the entire business process the business wants to automate.

What is an API integration?

The API is the interface. The integration is the specific solution that uses the interface.

Imagine:

CRM -> integration -> accounting system

Among other things, the integration must decide:

• which customers should be sent
• which fields should be mapped
• which system owns each field
• when data should be moved
• how data is validated
• what happens when an error occurs
• how duplicates are avoided
• how operations are monitored

This is why the logic between systems is often the difficult part. An API call may be simple, while the correct business rule requires much more clarification.

For a business, an API integration can connect two systems without replacing either of them. Common examples include CRM API integration, ERP API integration, sending orders to accounting software or making existing customer data available in a portal. The right approach depends on the process, the data and the operational requirements — not only on whether an endpoint exists.

System integration is the broader term for connecting business systems. An API integration is one way to do that, alongside native connectors, file exchange, database connections or automation platforms.

A concrete example of an API integration

Imagine an online shop where an approved order needs to be created in the accounting system.

A simple flow could look like this:

1. The online shop records that the order has been approved.
2. The integration retrieves the relevant order and customer data.
3. The data is validated.
4. The customer is matched to an existing customer or created.
5. The order is mapped to the accounting system’s fields.
6. The integration sends the order.
7. The external ID is saved back.
8. The result is logged.
9. Temporary errors can be retried.
10. Permanent errors can be sent for manual review.

The important question is not only whether both systems “have an API”. The integration must know what counts as the same customer, which fields are required and what should happen if the destination rejects the data.

When does an API integration make sense?

1. The same data is entered several times

If customer details are first created in the CRM and then manually entered into the accounting system and an internal tool, there is both time spent and a risk of different versions of the same data.

An integration can move the relevant fields automatically according to a fixed rule.

2. Information needs to be up to date in several places

Order status, payment status or inventory data may be examples where several systems need the same current information.

The question here is not only whether data should be synchronised, but also how quickly.

3. A website or web app needs data from another system

A B2B customer portal may, for example, show documents, order status or financial data that already exists in other systems.

The portal does not need to own all the data itself. It can use integrations to retrieve or send the information the customer needs.

4. Export and import are repeated

A CSV import once a month may be perfectly reasonable. If employees export and import data many times during a working day, however, the process is worth investigating.

5. An event should start the next step automatically

Example:

payment received -> project activated -> responsible employee alerted

Here, the API is part of a larger automation.

6. Data needs to be collected for reporting

If a dashboard should replace manual spreadsheets, integrations can retrieve data from the systems where it already originates.

When should you not build an API integration?

The systems already have a good native integration

If the platform’s own connector covers the workflow reliably, it is often better to use that than to build custom functionality.

Data is moved rarely

A manual CSV import may be cheaper and more robust at a low frequency.

Source data is poor

If customer names, IDs or status values are already inconsistent, an integration merely automates the problem faster. Data quality may need to be addressed first.

The process is unclear

An API cannot decide who should own a status or what should happen in a conflict. That business rule must be clarified before coding.

The API does not support the workflow

A system can have an API without providing access to the necessary endpoints, fields or actions. Documentation and access should therefore be checked early.

The value is too low

Technical possibility is not the same as business value. If the process happens only a few times a year, the integration’s operations and maintenance may cost more than the manual task.

Start with the process — not the endpoint

Before anyone writes code, the business should be able to describe:

• Which process should be improved?
• Where does the data originate?
• Where should it go?
• Who uses it?
• How quickly does it need to arrive?
• What happens if it is missing?
• What happens if the destination is down?
• Who owns the process?

Example: “When a customer is marked as won in the CRM, the customer should be created in the accounting system by the next working day.”

That is a better integration scope than: “We need the customer endpoint.”

The first describes the trigger, business value and timing. The second only describes a technical possibility.

Which system owns the data?

One of the most important decisions is the source of truth or system of record: which system is the authoritative source for a particular field?

Example:

CRM owns:

• customer name
• salesperson
• segment

Accounting system owns:

• invoices
• payment status
• balance

Online shop owns:

• order lines
• product selection

If every system is allowed to change every field, conflicts become difficult to resolve. An integration should therefore have explicit rules for data ownership.

One-way or two-way synchronisation?

One-way sync is typically:

A -> B

This is often simpler because one system is clearly the source.

Two-way sync is:

A <-> B

It may be necessary, but it increases complexity. Among other things, you need to define:

• what happens when changes are made at the same time
• which timestamp to trust
• which system takes priority
• how sync loops are avoided
• what happens with partial failures

Two-way synchronisation should therefore not be chosen simply because it is technically possible. Use it when both systems genuinely need to own changes.

Data mapping: systems do not call things the same

A CRM may call a field:

customer_id

while the accounting system calls the same business object:

debtor_number

The integration must know that the two are related.

Data mapping often includes:

• field names
• data types
• required fields
• currency
• date formats
• status values
• country and language codes
• internal and external IDs

Getting the meaning of the data right is often more work than sending the HTTP request itself.

Validating data before sending it on

An integration should not blindly copy everything.

Examples of data that should be handled deliberately include:

• missing email address
• invalid date
• unknown status
• negative quantity
• missing customer ID
• empty required field

Depending on the process, the integration can:

• reject the record
• log the error
• place the record in a queue
• use a defined fallback
• send the record for manual review

The important thing is that invalid data does not disappear silently or create unpredictable results.

REST API, webhook, polling or batch?

REST API

A REST API is often used as request/response: the integration asks for or sends something and receives a response.

Webhook

A webhook reverses the direction: System A sends a message to the integration when something specific has happened.

Polling

The integration asks at fixed intervals: “Have any new or changed data appeared since last time?”

Batch or import

Data is moved in groups — for example, an overnight synchronisation or file import.

No model is generally best. The choice depends on timing, data volume, API capabilities and how robust operations need to be.

Real-time is not always best

Real-time can be important for payments, critical order status or inventory information, where a delay of a few minutes has real consequences.

It is less important for, for example, overnight reporting or internal data that only changes a few times a day.

Real-time can increase the requirements for:

• monitoring
• event ordering
• retries
• duplicate handling
• queues
• error alerts

Choose the synchronisation frequency based on the business need — not because “real-time” sounds technically better.

Webhooks: how do they work?

A simple webhook flow could be:

1. An order is created in System A.
2. System A sends an event to the integration’s webhook URL.
3. The integration validates the sender and payload.
4. The action is performed in System B.
5. The event ID is stored or logged.

Webhooks should be designed for the possibility that events may be delivered again. If the same order event is processed twice, the integration should recognise it and avoid creating two orders.

Signatures, tokens or other mechanisms can be used to verify that the webhook comes from the expected sender, depending on the system’s documentation.

Errors are part of integration design

An integration that only works on the happy path is not finished.

Realistic errors include:

• timeout
• API is down
• 401 or 403
• 429 rate limit
• 5xx server error
• invalid payload
• changed data format
• missing field
• duplicate
• missing mapping

For each important error, ask:

Should we retry, stop, alert someone or send the record for manual processing?

This is often the part that determines whether the integration can operate reliably in production.

Retry: when should you try again?

Some errors are temporary. A timeout or temporary 503 may disappear on the next attempt. A 429 typically means that the client has sent too many requests and should respect the API’s rate-limit behaviour.

Other errors should normally not simply be retried again and again:

• invalid data
• missing permission
• unknown customer
• field no longer exists

Temporary errors are often handled with exponential backoff: the next attempt waits longer than the previous one so the integration does not send even more requests to an overloaded API.

Idempotency: how to avoid duplicates

Imagine that the integration sends an order and then receives a timeout. It now does not know whether the accounting system managed to create the order before the connection was lost.

If it simply sends the same request again, a duplicate may be created.

A robust integration can use, among other things:

• idempotency key
• external reference ID
• lookup before creation
• deduplication logic

In practice, idempotency means that the same logical attempt should not create several business results simply because the request had to be sent again.

Rate limits

Many APIs limit how many requests a client may send over a period of time.

This affects:

• how often data can be synchronised
• how large batches should be
• how retries are scheduled
• whether a queue is needed
• how quickly historical data can be migrated

Rate limits must be read in the specific API’s documentation. They should not be guessed.

Pagination

An API often returns data in pages or batches instead of all at once.

An integration must therefore be able to retrieve the next page until the dataset is complete.

Typical errors include:

• only the first page is imported
• cursor or page token is handled incorrectly
• records are skipped
• data changes during a long pagination process

For large datasets, pagination and the synchronisation strategy should be tested with realistic volumes.

Authentication and access

APIs can use different access models, such as:

• API keys
• OAuth
• access tokens
• service accounts

The main principle should be least privilege: the integration receives only the permissions it actually needs.

In addition:

• secrets should not be hardcoded in frontend code
• credentials should be rotatable
• test and production should be separated
• tokens should be treated as sensitive credentials
• access should be removed when the integration is no longer used

With OAuth, scopes should be limited to the necessary resources and actions.

Personal data and GDPR

If the integration moves personal data, data protection should be part of the design — not a task after launch.

Practical questions include:

• Which personal data is actually necessary?
• Who is the data controller and any data processor?
• Who has access?
• How long should data and logs be stored?
• Which systems and suppliers receive the data?
• Do logs contain sensitive payloads?

Only move the data the process needs, and avoid logging passwords, tokens or complete sensitive payloads without a clear need.

The legal responsibility depends on the specific processing and should be assessed separately. This guide is technical decision support, not legal advice.

Logging: what should the integration be able to tell you?

When something fails, you should be able to answer:

• What happened?
• When did it happen?
• Which system was involved?
• Which operation was attempted?
• Did it succeed?
• Which reference ID was involved?
• What was the error?

Logs should be useful without becoming a copy of all sensitive data.

A good reference ID makes it possible to follow the same customer, order or event through several steps without storing more personal data than necessary.

Monitoring and alerts

An integration can appear to be “running” even though it is effectively broken.

For example: a nightly job starts every day, but all requests are rejected because access has expired. If nobody monitors the result, the error can remain for days.

Monitoring should be able to detect, for example:

• rising error rate
• jobs that do not run
• growing queue
• authentication failures
• rate limits
• delayed synchronisation
• recurring permanent errors

There must also be an owner who actually responds to the alerts.

API versions and changes

Third-party APIs change.

They may:

• add or change fields
• change authentication
• deprecate endpoints
• introduce a new version
• change rate limits or validation rules

That is why an integration is not “build once and forget”.

Documentation, monitoring and responsibility for future changes should be part of the operations plan.

Test environment and sandbox

A test environment is valuable because the integration can be tested without:

• creating real invoices
• sending emails to customers
• changing production data
• creating fake live orders

Not every API offers a good sandbox. This should be investigated early because a lack of testing options affects both scope and risk.

How to scope the first integration

Start with one data flow.

Example:

When customer is won in CRM -> create customer in accounting system

Define:

• trigger
• source
• destination
• fields
• data ownership
• mapping
• validation
• sync frequency
• error scenarios
• retries
• logging
• monitoring
• success criterion

Only then does an estimate provide a responsible basis for a decision.

10 error scenarios to know before development

1. The API does not respond.
2. The access token has expired.
3. The customer already exists.
4. A required field is missing.
5. The rate limit has been reached.
6. The destination returns 5xx.
7. A webhook event is delivered twice.
8. The data format or a field changes.
9. The destination permanently rejects the data.
10. A batch stops halfway through processing.

You do not need to predict every possible error. But the most likely failure modes should have a known handling strategy.

Native integration, automation platform or custom API integration?

It is often a mistake to jump directly to custom code. If a native integration solves the need robustly, it is normally worth trying first.

API integration vs. automation

Automation is the broader concept. An API integration is one technical method that often forms part of the automation.

Example:

When status changes in CRM -> send data to accounting system -> create task -> alert employee

The APIs connect the systems. The automation describes the entire workflow.

If the need is primarily about removing recurring manual steps, it may therefore be relevant to first assess workflow automation.

API integration vs. internal system

An integration moves or coordinates data between existing systems.

An internal system gives employees a user interface, roles and a specific workflow.

The two are often used together:

CRM -> integration -> internal dashboard

The integration moves the data. The dashboard makes it useful in the work.

API integration vs. custom web app

A custom web application can use integrations for CRM, payments, accounting, ERP, email or other data sources.

The API integration is therefore often one component in a larger solution — not the end product itself.

An integration flow from CRM to accounting system

A more complete flow could be:

1. A trigger records that the customer is ready for transfer.
2. The integration retrieves the necessary data.
3. The data is validated.
4. Fields are mapped to the destination’s model.
5. Existing customers are checked for.
6. The integration authenticates with the destination.
7. The data is sent.
8. The response is checked.
9. The external ID is saved.
10. The result is logged.
11. Temporary errors are retried.
12. Permanent errors trigger an alert or manual task.

Once the 12 steps have been described, it is much easier to assess complexity and risk than by simply counting endpoints.

What affects complexity?

Complexity depends, among other things, on:

• number of systems and endpoints
• number of data fields
• sync direction
• data mapping
• data quality
• API documentation
• authentication
• test environment
• real-time requirements
• historical data
• error handling
• monitoring
• rate limits
• pagination
• webhooks
• security
• ongoing maintenance

That is why a specific API integration project should only be estimated once the data flow and API access have been investigated. This article should not be treated as a general pricing guide.

What should the business have ready before an estimate?

• the systems that need to be connected
• API documentation
• access type
• sandbox or test environment
• relevant endpoints
• data fields
• source of truth
• sync direction
• desired frequency
• known error scenarios
• real-time needs
• expected data volume
• responsible system owner

If several of these points are still unknown, the first deliverable should be technical clarification rather than a large development scope.

How to assess whether an API integration is the next step

An integration is worth investigating if:

• the same data is entered into several systems
• manual exports and imports recur
• data needs to be consistent across systems
• a website or web app lacks data from an existing system
• customers need to see data from underlying systems
• a workflow stops because systems do not communicate
• the process is stable and well-defined
• useful API access exists

Consider something simpler if:

• the task happens rarely
• a native integration already solves it
• data quality is poor
• the process is not yet stable
• real-time does not create real value
• the API does not support the workflow

An API integration is not finished at launch

After launch, there should be a plan for:

• monitoring
• error alerts
• credentials and rotation
• API versions
• documentation
• responsibility
• testing when changes are made
• third-party deprecations

An integration has external dependencies. This should be reflected in operations.

A good integration therefore does not start by choosing an endpoint. It starts by defining data ownership, the flow, error scenarios and what the business is actually trying to improve.

If the process is clear but the technical connection between the systems is missing, AS Web Solutions can help clarify API access, data flow and a realistic first version.

FAQ

What is an API integration?

An API integration is software logic that uses one or more APIs to move or process data between systems according to defined rules.

What is the difference between an API and an integration?

The API is the system’s technical interface. The integration is the specific solution that uses the API for a particular data flow or workflow.

What is the difference between an API and a webhook?

An API is often used when the integration actively sends or retrieves data. A webhook is typically used when a system sends a message after an event has occurred.

Does an integration need to be real-time?

No. Real-time only makes sense when the business needs very fast updates. Batch or scheduled synchronisation can be simpler and more robust.

What happens if an API goes down?

The integration should have timeouts, logs and a plan for temporary errors. Some operations can be retried safely, while others require manual handling.

Can two systems synchronise in both directions?

Yes, but two-way sync requires clear rules for conflicts, data ownership and simultaneous changes. One-way sync is often simpler.

What is an API key?

An API key is a credential that a system can use to identify or authorise a client. It should be treated as a secret and must not be exposed carelessly.

Can an integration create duplicates?

Yes, especially with retries or repeated events. External reference IDs, idempotency and deduplication logic can reduce the risk.

Can an API integrate with a CRM or accounting system?

That depends on the specific system’s API, access model and required endpoints. An API can exist without supporting the particular workflow you want.

What needs to be ready before an integration project?

At a minimum: the two systems, desired data flow, API documentation, relevant fields, source of truth, sync direction, timing, test access and key error scenarios.