API Integration in Singapore: What to Check Before Connecting Business Systems
An API integration lets one system send data to another, or ask it to do something, without a person copying information between them. Connecting a website to a supplier, an online store to an accounting package, or a SaaS product to a payment provider are all common examples.
Whether an integration works well usually comes down to a few decisions made before development starts. You need to know what the other system's API actually allows, which system is the source of truth for each record, what happens when a request fails halfway, how credentials are protected and who looks after the connection once it is live. This guide walks through those decisions for business owners commissioning a web application or connecting existing software, including SaaS founders deciding how much to invest in their own API.
What an API does
An API (application programming interface) is a defined set of requests that a system agrees to accept from other software, along with the responses it will send back. A supplier's API might accept "create this order" and reply with an order number. An accounting system's API might accept "here is a new invoice" and confirm it was saved.
There are two quite different kinds of API work, and it helps to know which one you are buying.
Using an existing API means connecting your system to one someone else built and runs, such as Stripe, Xero, Shopify or a supplier's ordering system. You work within the provider's rules: the operations it offers, its limits, its pricing and its schedule for changing things. Many business integrations are this kind.
Developing your own API means your application exposes its own set of requests for other software to use. This could be for your own mobile app, for customers who want to connect their systems to your SaaS product, or for partners. Here you define the rules, and you also take on the job of documenting them, securing them and keeping them stable for whoever depends on them.
An API is not always the right tool. For a jointing company, we built a payment claim app that works alongside the client's existing system and exchanges data with it through file export and import. That kept the project focused and avoided replacing a system the business already relied on. If data only needs to move once a day, or the other system has no usable API, a scheduled file exchange can be the simpler and more reliable choice. Our guide to custom web application development covers the broader decision between buying, connecting and building.
Check the provider's API before committing
Integration problems discovered after a project has been scoped and priced are costly to fix. Before committing, someone technical should read the provider's documentation and confirm the following:
- Does it support the exact operations you need? A feature visible in the provider's dashboard is not always available through its API. Check each action the integration depends on, such as creating an order, checking its status, cancelling it or reading stock levels.
- What permissions and approval are required? Some providers grant API access only to certain account types, require an application review, or split access into scopes that must be requested separately.
- Do subscription tiers restrict usage? Limits are often tied to your plan. Xero, for example, moved to tiered developer pricing in March 2026. Its free Starter tier allows 5 connected organisations and 1,000 API calls per organisation per day, while paid tiers allow 5,000, and some endpoints such as Journals are only available on higher tiers (Xero developer pricing).
- Is the documentation complete and current? Look for clear descriptions of each request, error codes, rate limits and a changelog. Thin or outdated documentation means more of the budget goes into trial and error.
- How does the provider handle versions? For its versioned APIs, Shopify releases a new version every quarter and supports each stable version for at least 12 months (Shopify API versioning). That is a predictable schedule, but it means regular review and upgrades before the version you use loses support.
- Is there a test environment? Stripe provides test mode and sandboxes, so payments can be tested without moving real money. Many smaller suppliers offer nothing similar. If every call to the live API has real consequences, agree how the integration will be tested before launch.
If the answers are unclear, a short paid discovery or proof of concept that makes a few real calls to the provider's API is usually cheaper than building on assumptions.
Decide where each piece of information is updated
When two systems hold the same information, agree which one your team actually updates. If a customer changes their phone number, does staff update it in the CRM and let the website pick it up, or can the customer also change it on the website? The simplest arrangement is to pick one system for each type of information. Customer details might be managed in your CRM (see custom CRM development cost), stock levels come from your supplier, and invoice status lives in your accounting software. The other systems then receive those updates and do not change them.
Next, the information has to be matched up, because two systems rarely describe things the same way. Your website might mark an order "completed" once it has been paid, while your supplier uses the same word only after delivery. Product codes, tax settings and address formats often differ too. Someone who knows the business should go through these with the developer and decide how each one translates, since the right answer depends on how your business works and cannot be worked out from the data alone.
Then decide how quickly a change needs to reach the other system. An order that must reach the supplier before the customer sees a confirmation has to go across straight away. Stock levels might be fine updating every hour, and a summary for your accountant could go once a day. Instant updates take more work to build and test, so ask for that speed only where the business needs it.
Finally, consider what happens if someone edits the same record in both systems before they have synced. With one system in charge of each type of information, this rarely comes up. If staff do need to edit in both places, agree a rule in advance, such as applying the most recent change or flagging the record for someone to check. Without a rule, one edit can quietly overwrite another, and nobody notices until a customer points it out.
Plan for failed and repeated requests
Every request between two systems can fail, and the awkward failures are the ones where you do not know what happened. A reliable integration needs a plan for each of these cases.
Timeouts leave the outcome unknown
A timeout is the point at which your system stops waiting for a reply. Without one, a slow provider can leave your application stuck. With one, you face a different problem: the request may have succeeded on the provider's side even though no confirmation arrived. If your system simply tries again, it may create a second order, a second payment or a second invoice.
Retries need limits and spacing
Retrying is reasonable for temporary failures, but uncontrolled retries make outages worse. AWS's engineering guidance describes retries as "selfish", because each one adds load to a system that may already be struggling, and recommends exponential backoff with jitter: waiting progressively longer between attempts, with some randomness so many clients do not retry at the same moment (AWS Builders' Library). A sensible integration retries a limited number of times, then stops and flags the problem for a person.
Idempotency prevents duplicate operations
An operation is idempotent if repeating it has the same effect as doing it once. Some providers support this directly. Stripe, for example, accepts an idempotency key with supported requests, so your system can retry without duplicating an operation that has already succeeded. Each provider has its own rules on how long keys are kept and which request details must match, so follow its documentation (Stripe idempotent requests). The same AWS guidance notes that APIs with side effects are not safe to retry unless they provide idempotency.
When a provider offers nothing like this, your system has to protect itself as far as it can. Recording each outgoing request with your own reference before sending it makes every attempt traceable. That reference only prevents duplicates on the provider's side if the provider lets you look it up or rejects repeats, so check whether it does. Where the outcome is still uncertain, hold the request for reconciliation or manual review instead of resending it automatically.
Webhooks can arrive late, twice or out of order
Webhooks, where the other system sends yours a message when something happens, are convenient, but delivery is not as tidy as it looks. Stripe, for example, retries failed webhook deliveries for up to three days in live mode, says an endpoint may occasionally receive the same event more than once, and does not guarantee events arrive in the order they were created (Stripe webhooks). Its recommendations are good practice with other providers too: verify that each webhook genuinely came from the provider, save or queue the event before confirming receipt, do the heavier processing afterwards, and record event IDs so duplicates are ignored. Saving the event first matters because if your system confirms receipt and then crashes, the provider will not resend it. It is also worth having a scheduled check that compares records between the systems, in case a webhook never arrives at all.
Rate limits cap how fast you can go
Providers limit how many requests you can send in a period. Xero allows 60 calls per minute for each connected organisation, with no more than 5 requests in progress at once, and a daily allowance of 1,000 or 5,000 calls per organisation depending on the app's pricing tier (Xero API limits). When a limit is exceeded, APIs typically respond with HTTP status 429 (Too Many Requests), often with a Retry-After header saying how long to wait (MDN). Limits matter most for bulk jobs such as an initial import of thousands of products, which may need to be spread over hours or days.
A real example: automating orders through a supplier's API
One of our website projects was for a game top-up retailer, built with a custom frontend on a WooCommerce backend. Part of the scope was connecting the supplier's existing API to automate the client's orders.
We will not go into the implementation here, but this type of integration shows why the earlier sections matter. Where customer orders go through to a supplier, a duplicated request can have a direct cost, and an unclear failure can leave a customer waiting for something they have paid for. The supplier's available operations, its test options, how failed requests are detected and how the order status on the website stays in step with the supplier all need answers during scoping.
Protect credentials and access
Integrations involve two separate security questions. Authentication confirms who is making a request. Authorisation decides what that caller is allowed to do.
When you connect to someone else's API
The credentials your system uses (API keys, client secrets, access tokens) give access to your account with the provider. A few practices go a long way:
- Keep secret API keys, client secrets and privileged server credentials on the server and out of browser or mobile app code, where anyone can extract them. Some providers issue separate public keys designed for client-side use, such as Stripe's publishable keys, and those are fine in the frontend. This is especially relevant for custom frontends that talk to several services.
- Store them in environment variables or a secrets manager, never in the source code repository.
- Request only the permissions the integration needs. A connection that only reads stock levels should not hold a key that can issue refunds.
- Rotate credentials when staff or vendors with access leave, and when you suspect a leak.
If the integration passes personal data between systems, the PDPA applies to that transfer too, including where each provider processes it. Our guide to the PDPA for web applications covers what to check.
Data coming back from a provider also deserves checking. OWASP's API Security Top 10 includes "unsafe consumption of APIs", where developers trust data from third-party APIs more than user input (OWASP API Security Top 10 2023). Validate what arrives before saving it or showing it to users.
When you build your own API
A common serious API security flaw is letting one user reach records they should not see. OWASP ranks broken object level authorisation first in its 2023 list: the API accepts a record ID in the request but fails to check that the logged-in user is allowed to access that record. Its recommended fix is to check, in every function that accesses a record by ID, that the current user has permission to perform that action on that specific record. Ownership is not always the test, since some records are legitimately shared between several users (OWASP API1:2023).
For a SaaS product, this check has to cover the customer account as well as the individual user, so one business can never read another business's data by changing a number in a request. How tenants are separated is covered in our SaaS development cost guide. Your own API also needs rate limits of its own, since OWASP lists unrestricted resource consumption among the top risks.
When API-first design helps a SaaS product
Two terms often get blurred together here.
API-first is a product strategy. It means treating APIs as a core part of the product from the start, planned alongside the web interface. That can include private APIs for your own apps, partner APIs and public APIs for customers. Whether all of them share a single API is a separate architectural choice.
Design-first is an implementation method. It means writing the API contract (the description of each request, response, error and permission) before writing the code. The OpenAPI Specification is the common format for this; it describes HTTP APIs in a way that both people and software can read without access to the source code (OpenAPI Specification). The OpenAPI Initiative's own guidance recommends design-first, partly because it forces the team to agree the interface before code makes it hard to change (OpenAPI best practices).
You can use one without the other. A small product can write its contract first without making the API a public product, and a company can declare itself API-first while documenting everything after the fact.
When it is worth the effort
API-first tends to pay off when:
- the product will have more than one client application, such as a web app and a mobile app
- customers or partners will connect their own systems, which makes the API part of what they are paying for
- separate frontend and backend developers need to work in parallel against an agreed contract
In those cases, a written contract gives everyone the same reference. Documentation can be generated from it, frontend work can start against mock responses before the backend is finished, and automated tests can check that the code still matches what was promised. A published versioning and deprecation policy then tells integrators how much notice they will get before something changes.
What an API boundary does not give you
Putting an API between parts of a system does not by itself mean those parts can scale independently. A shared database, or a request that has to wait on a chain of calls between services, can still create a bottleneck. How much that matters depends on the workload and how the system is built.
It also does not automatically speed up development. A public API is a commitment: once customers depend on it, changes need versioning, migration notes and support for older versions. For an early SaaS product with one web interface and a small team, a well-structured application with a clean internal API is often enough, with a public API added when customers actually ask for it. We have built APIs for clients' own products, and the decision about how formal to make them is best made against the product's real users and roadmap.
After launch: monitoring, troubleshooting and provider changes
Going live is where an integration's maintenance starts. Providers change their APIs, credentials expire, rate limits get hit during busy periods, and occasionally the other system is simply down.
We set up failure logs that send an email alert when an integration stops working, so problems can be picked up before a customer reports them. Alongside that, these practices are common across well-run integrations:
- Logging each request and response with an order or record reference, so you can answer "did the supplier actually receive this?" without guesswork. Logs should leave out credentials and unnecessary personal data.
- A queue of failed operations that staff or developers can review and re-run once the cause is fixed.
- A scheduled reconciliation that compares records in both systems and flags mismatches.
- Tracking the provider's changelog and deprecation notices, and scheduling version upgrades before old versions are retired.
- Monitoring credential and token expiry so a connection does not quietly stop working.
Ongoing integration work like this usually sits within a maintenance arrangement. Ours start from S$500 per month, and our guide to web app maintenance costs explains what that covers.
Frequently asked questions
What is the difference between an API and an integration?
The API is the interface a system offers. The integration is the work that connects two systems through their APIs, including matching up the data, handling errors, security and monitoring. A provider having an API does not mean the integration you need already exists.
Can I connect two systems without custom development?
Often, yes. Workflow tools such as n8n can call standard web APIs, including ones without a ready-made connector, and support error-handling workflows. The choice depends on how critical the transactions are, the volume and speed required, who will maintain the workflow, and whether the integration needs its own interface for staff or customers. Our guide to business process automation explains where that line usually falls.
What if the other system has no API?
Check whether it can export and import files, as covered earlier. If it offers neither an API nor file exports, ask the vendor whether either is planned. Workarounds that copy data from the system's screens automatically tend to break when those screens change, so treat them as a last resort.
Can an integration break after launch even if nothing changed on our side?
Yes. Providers retire API versions, change limits and pricing, and update how their data is structured. Monitoring and planned maintenance keep these changes from turning into outages.
Is API-first worth it for an early SaaS MVP?
Usually only in part. It helps to write down early how your app's screens will get data from your system, because it makes everyone clear on what the first version needs to do. Building a polished API for customers to connect to is a different matter. If no customer has asked for one yet, it is usually too early to spend money on it. Just make sure the system is built so that customer access can be added later. Our MVP development cost guide covers how to keep a first version lean.
Connecting a Supplier, Payment Provider or Accounting System?
If you are planning an integration, the useful first step is checking the provider's API against what your business needs it to do, before anything is priced or built. That check also shows whether an API is the right approach at all, or whether a simpler file exchange or automation tool would do the job.
retroXpect connects websites and web applications to third-party APIs, builds custom applications with their own APIs, and maintains integrations after launch, including failure logs with email alerts. We usually build integrations as part of a wider system, but we also take on standalone connections, quoted after scoping. Message us on WhatsApp with the systems you want to connect and what should happen between them, and we will tell you what we would check first.
