Building an API to open your system to partners

Your customers call to ask about their order status. Your distributors re-enter your catalog into their own system. Your carrier sends you Excel files. An API (application programming interface) ends these manual exchanges: it lets your partners’ systems talk directly to yours. Here is when it makes sense, what it costs, and how to design it properly.

What an API actually delivers

An API is a controlled entry point into your system. An authorized partner can, depending on the permissions you grant:

• read: available stock, net prices, order status, tracking number;
• send: an order, a quote request, a signed delivery note;
• get notified: your system alerts them when an order ships or an invoice is issued (this is called a webhook).

For a decision-maker, the value is measured in re-entry avoided, fewer errors and follow-up calls that disappear. It is also a sales argument: a large account is more likely to choose a supplier that plugs into its own tools.

API, export or portal: picking the right level

An API is not always the best answer. Compare it with simpler options:

In practice, many companies combine a portal for smaller customers and an API for key accounts. Both rely on the same data and the same business rules.

What a well-designed API looks like

I build APIs around a few simple principles that you can demand from any provider:

1. Published documentation in the standard OpenAPI format, which a partner’s IT team can read and test without calling you.
2. Access per partner: each partner has its own credentials, which can be revoked at any time, and only sees its own data.
3. A separate test environment, so partners can develop without touching your real orders.
4. Versioning: when the API changes, the previous version keeps working while partners migrate.
5. A call log, so you know who read or changed what, and can diagnose a problem quickly.

Security, point by point

An API opens a door into your information system. The OWASP API Security project, an international reference in application security, publishes a ranking of the most common risks (2023 edition, checked in October 2026). At the top: broken authorization checks, which let one partner access another’s data just by changing an ID in a request.

In practice, I plan for:

• authentication with a key or token (OAuth 2.0 for the most demanding cases);
• permission checks on every request, not just at sign-in;
• rate limits per partner, so an error on their side cannot overload your system;
• encryption in transit (HTTPS) and logging.

These points are covered in more detail in the most common security flaws in SMB applications.

What an API costs

There are two scenarios:

• Adding an API to an app I am building: this is the “connection to other tools” module, priced at $2,300 (€2,000)excl. VAT in the estimator. It covers a focused API (a few resources, read and write, documentation). Several separate flows or partners with very different needs increase that amount.
• Building an API around an existing system (ERP, in-house database): this is a business app project in its own right, $6,800 to $22,400 (€6,000–€20,000)excl. VAT and 1 to 3 months depending on the number of resources exposed, the developer area and partner account management. I start with an audit of the existing system to check what can be accessed.

Hosting and maintenance come on top, usually modest unless call volumes are very high.

When an API is not the right answer

• Your partners have no IT team: they will not use it. A portal or an export will be more useful.
• Exchanges go through a mandated standard, such as EDI with large retailers: see EDI for SMBs.
• One partner, one file a day: a scheduled export is enough and costs less.
• Your internal system is unreliable: exposing wrong data to partners makes the problem worse. Fix the source first.

Where to start

1. List your partners’ requests: which data, how often, in which direction.
2. Pick two or three pilot partners willing to connect first.
3. During the discovery call, we choose the right level: export, webhook, API or portal.
4. During scoping, I write up the list of resources, access rules and a fixed quote; the documentation ships with the API.

The API then opens to the pilot partners, gets adjusted based on their feedback, and then opens to everyone else.