API Development and System Integration

When a business needs its own API or integration

This work is for teams that need to connect specific systems or open their application's data to others. The most common situations:

• Internal integration: store orders should reach the ERP, invoices the accounting package and shipping statuses should flow back to the customer, with nobody retyping anything.
• Vendor integration: a payment provider, carrier, marketing platform or e-invoicing system (in Poland, KSeF) offers an API and your application has to use it reliably.
• API for partners or a mobile app: your product needs a stable interface consumed by a front end, a mobile app or partner systems.
• Integration layer: instead of a dozen point-to-point links, one integration service translates data between systems and is the only place to change when you replace a vendor.

If the API is meant to be sold as a product with plans and billing, see API as a product. If the need is moving large volumes into a warehouse on a schedule, see ETL pipelines and connectors.

What a well-designed API includes

Resource model and contract

We define which objects the interface exposes (customer, order, line item, payment and so on), which operations are allowed and what every response looks like. The contract lives in OpenAPI, so one file produces the documentation, a mock server and compatibility tests.

Validation, idempotency and a consistent error format

Every request is validated on entry. Operations that create data accept an idempotency key, so a retried call never duplicates an order. Errors share one format with a code, a description and the offending field, for example following RFC 9457 (Problem Details).

Pagination, filtering and rate limits

Lists are paginated, preferably with cursors, and have predictable filters and sorting. Rate limits protect the system from a single heavy client or a runaway loop in someone else's integration.

Webhooks and events

Instead of polling the API every minute, a partner system can be notified of changes. We sign webhooks (HMAC, for instance), retry them with exponential backoff and keep a delivery history, so anyone can check whether a message arrived.

Versioning

Non-breaking changes ship without a new version; breaking changes go into a new version with a transition period that you decide. The policy is written down before the first external consumer appears.

Integration patterns and the systems we connect

The right pattern depends on how fast data must arrive and what the other side offers:

• synchronous API call when a user is waiting for the result (stock check, shipping quote);
• events through a queue when guaranteed delivery matters more than immediacy (passing an order to the ERP);
• webhooks when the vendor announces a change itself (payment status);
• polling adapter for systems that only expose a change list or a report;
• file exchange (SFTP, CSV, XML) for older systems without an API, with validation and a processing acknowledgement for each file.

Typical system classes are ERP and accounting software, CRM, e-commerce platforms, payment providers, carriers, identity providers (Microsoft Entra ID, Google Workspace, Keycloak) and public-administration systems. Before committing to a date we check each vendor's documentation, sandbox availability, rate limits and access terms.

Architecture and technology

We build the API in a technology your team knows and your infrastructure supports: Node.js (e.g. NestJS), .NET (ASP.NET Core), Python (FastAPI or Django) or PHP (Laravel, Symfony). For heavy service-to-service traffic we consider gRPC; for front ends that need many different slices of data, GraphQL. For most business integrations, REST with OpenAPI remains the simplest and best-supported choice.

Around the code you need an API gateway or reverse proxy (TLS, limits, logging), a queue for asynchronous operations, a database holding integration state and message history, and a secrets manager. Deployment is usually containerised, in your cloud account (AWS, Azure, Google Cloud) or on-premise servers, with a CI/CD pipeline and a separate test environment.

Security and compliance

APIs are among the most frequently attacked parts of any system, so security is designed together with the contract rather than bolted on afterwards. Our reference point is the OWASP API Security Top 10:

• authentication matched to the consumer: OAuth 2.0 and OpenID Connect for users, client credentials or narrowly scoped keys for systems, mTLS where a partner requires it;
• object-level authorisation, so customer A cannot read customer B's order by changing an ID in the URL;
• replay protection, rate limits and input size checks;
• an audit log of who changed what and when, without recording passwords, tokens or unnecessary personal data;
• GDPR: minimal transferred fields, defined log retention and a documented map of personal-data flows.

If the integration touches payment accounts, PSD2 requirements apply on the bank's or payment provider's side. We reflect them in the technical design, but this is not legal advice.

How the project runs

1. Discovery: we map systems, data owners, flow directions and conflict rules, meaning which system is the source of truth for each field.
2. Specification: OpenAPI contract, error scenarios, performance requirements and exclusions. The binding price is based on this document.
3. Mock server: a contract-compliant mock lets your front end or partners start work in parallel.
4. Iterative build: first the most important flow end to end, then further resources and edge cases.
5. Testing and acceptance: unit, contract and integration tests against vendor sandboxes, including lost connections, duplicates and malformed data.
6. Launch: deployment with monitoring, a rollback plan and an operations guide for whoever maintains it.
7. Maintenance: reacting to vendor changes, dependency updates and further development, for example under software maintenance.

A focused integration is usually measured in weeks. The biggest sources of delay are missing vendor sandboxes, waiting for access, unclear business rules and the number of systems changing at the same time.

What drives the price

The indicative starting point is $1,900 excluding VAT. That covers one focused integration or a small API with a few resources, authentication, tests and documentation. The figure rises with:

• the number of systems, endpoints and sync directions (two-way sync costs noticeably more than one-way);
• the documentation quality and stability of vendor APIs;
• the complexity of data mapping and conflict rules;
• availability, performance and audit requirements;
• a one-off transfer of historical data;
• connecting a legacy system that has no API.

The proposal offers three options, Essential, Recommended and Scale, and states clearly what is excluded: third-party API fees, integration-platform licences and cloud costs. All price anchors are compared on the pricing page.

What we need from you

• a business decision-maker and a technical contact for each system;
• vendors' API documentation and sandbox accounts;
• sample messages or files, ideally anonymised;
• a decision on which system is the source of truth for key data;
• information about hosting, security rules and your IT change-approval process.

Already have an outline? Send us a description of the systems and we will come back with clarifying questions and a discovery proposal. Related services are listed under data and APIs; if external developers will consume the API, consider an SDK as well.

Related services

Frequently asked questions