SmartLink
Software engineering

API integration services in Pakistan: cost, duration and ownership

API integration services in Pakistan get bought at two moments: when a new system has to talk to an old one, and when somebody finally counts the hours a week staff spend retyping the same order into a second screen. SmartLink Services designs, builds and publishes integration layers from Karachi, in REST with an OpenAPI specification, using webhooks or queues where the flow suits them better. What follows is the commercial detail. The market rate for an interface, how long one takes once the far end cooperates, and whether to licence an integration platform or hold the code yourself. Monitoring and an error runbook arrive with the interface rather than a year later.

Discuss this service
Style
REST \u00b7 webhook \u00b7 queue
Docs
OpenAPI published
Versioning
Backward-compatible
Overview

A published contract is what makes an integration supportable.

Integration work is judged eighteen months after it is delivered, which is why so much of it is judged badly. The interface was built under pressure at the end of a project, it worked on the day, and the specification was a conversation between two people who have since moved on. Then a field changes meaning, a consumer starts sending a slightly different payload, and the failure appears downstream as a number that does not reconcile. Tracing it takes days because nothing in the chain recorded what it received.

We treat the contract itself as the deliverable. An OpenAPI specification that is published, versioned and generated from the same definitions the implementation uses, so that it cannot quietly drift away from actual behaviour between releases. Authentication, rate limits and key management decided at design time rather than added hurriedly after an incident. Errors that say what was wrong with the request, in a form a consumer can act on programmatically, rather than a generic failure that sends somebody to a telephone.

Operability is the other half of the job and gets far less attention. Every endpoint logs a correlation identifier that follows a request across systems. Retries are idempotent, because a consumer that times out and retries should never create a duplicate order in your ledger. Failures that cannot be retried land somewhere visible, with enough context attached to be replayed later. None of this is advanced work. It is the difference between an integration anyone on duty can support and one only its author can.

Scope

What API & integration development covers

Everything below is agreed in writing before any development & saas work starts, so both sides know what is in and what is not.

What the work covers

  • Integration landscape assessment and pattern choice
  • REST API design, build and OpenAPI documentation
  • Authentication, rate limiting and key management
  • Webhook and event-driven flow implementation
  • Legacy system adapters where no API exists
  • Monitoring, logging and error alerting per endpoint

What you get at handover

  • Published OpenAPI specification
  • Deployed API with environments and keys
  • Integration monitoring dashboard
  • Error handling runbook
  • Consumer onboarding guide

Typically involves

REST / OpenAPI Postman suites
Discuss this service
01

Designing a resource model you will not regret in a year

The most common API design mistake is publishing the internal database structure with a thin layer over the top. It works immediately and it couples every consumer to your storage, so the first refactor becomes a breaking change for everybody who integrated. Designing the resources around what a consumer actually needs, rather than around how the data happens to be stored today, costs a little more thought at the start and preserves your ability to change your mind later.

Consistency is worth more than elegance. Identifiers formatted the same way everywhere, timestamps in one format with an explicit time zone, monetary values with an explicit currency and a stated precision, pagination that behaves identically on every collection, and errors with a stable machine readable code alongside the human readable message. A consumer integrating with five endpoints that each behave slightly differently will spend most of its budget on the differences rather than the work.

Decide early what is deliberately out of scope. An API trying to serve an internal service, a partner integration and a public developer audience all at once usually serves none of the three well, because their tolerance for change and their security requirements differ sharply from each other. Separating them, even where they share an implementation underneath, lets each one have an appropriate versioning and deprecation policy instead of a single awkward compromise that satisfies nobody and constrains everybody.

  • Resources modelled on consumer needs rather than on internal table structure
  • Identifiers, timestamps, currency handling and pagination consistent across every endpoint
  • Stable machine readable error codes alongside human readable messages
  • Internal, partner and public audiences separated so each gets an appropriate change policy
  • Contract generated from the same definitions the implementation uses, so it cannot drift
02

A deprecation policy is a promise

Versioning is easy to discuss and hard to honour under deadline pressure. Semantic versioning gives you the vocabulary: additive changes are minor, breaking changes are major, and the distinction has to be applied honestly rather than conveniently. Adding a required field to a request is breaking, even though it feels small. Tightening validation is breaking. Changing the meaning of an existing field without changing its name is the worst kind, because nothing fails loudly and the damage surfaces in somebody's reconciliation.

The policy that matters is what happens after a major version ships. How long the previous version keeps running, how consumers are told, whether usage of the old version is measured so you know who is still on it, and what happens to a consumer who ignores every notice you send. Answering those before the first version is published is far easier than negotiating them with an angry integration partner in the middle of a cutover weekend.

Measurement is what makes the policy enforceable rather than aspirational. If you can see which consumers called which version, and which deprecated fields are still actually being read, retirement becomes a short conversation with three named parties rather than a leap of faith taken on a quiet Friday. Without that visibility, teams keep old versions running indefinitely because nobody can prove they are unused, and the maintenance burden compounds quietly with every single release that follows.

  • Semantic versioning applied honestly, including to changes that feel minor at the time
  • A written policy covering support window, notification and what happens after it expires
  • Usage measured per version and per deprecated field, so retirement is evidence based
  • Deprecation signalled in the response itself as well as in the documentation
  • A consumer register, so the people affected by a change can actually be contacted
01

What API integration costs in Pakistan

Interfaces are priced one at a time, and any estimate covering an unspecified number of them is not an estimate. The nearest published market anchor is adding e-invoicing to an existing POS or ERP, quoted at PKR 150,000 to 400,000, and it is a fair reference point because a single documented flow in one direction, with a real acknowledgement coming back, is roughly that size of job. Broader work belongs against the custom web application band of PKR 200,000 to 1,000,000 and upwards, once several flows, a published contract and a monitoring dashboard are in scope.

Hourly rates published for this market run PKR 500 to 1,000 for junior work and PKR 3,500 to 8,000 for full stack development, with senior specialists at the top of that band. Integration is not junior work. It is the place where a small mistake becomes a payment file sent twice or an order posted against the wrong company, so the rate on this line is usually the senior one and an honest estimate says so.

What sets the price is the far end rather than your end. A current API with a sandbox, documented error codes and a support address is the cheap case. A closed product whose supplier replies in a fortnight is the expensive one, and a system with no interface at all means an adapter, a file drop or screen level automation, each carrying its own fragility. Certificates and key rotation add work. Volume changes the design outright, since a nightly file of four hundred rows and a live feed of forty thousand documents are not the same build. The item almost always underpriced is the failure path: retries, ordering, a dead letter queue, alerting and a reconciliation somebody actually reads each morning. Those are what make an interface survivable in its third year. Every figure here is market pricing. A real figure follows discovery, once the flows, the far systems and the volumes are written down.

  • Each interface priced individually, with the far system named in the estimate
  • FBR e-invoicing at a published PKR 150,000 to 400,000 as the nearest single flow comparator
  • Senior rates applied, because integration defects cost more than integration hours
  • Retries, ordering, dead letter handling, alerting and reconciliation costed as scope
  • Volume and frequency confirmed before a pattern is chosen, since they change the design
02

How long an API takes to build

Reported delivery timelines put a focused single scope go live at six to twelve weeks, and FBR integration specifically at six to twelve weeks, which is a useful published marker for one well defined interface with an external counterparty. A single flow between two systems you both control can be quicker. A set of flows with a service layer and monitoring in front of them belongs in the three to six month band.

Credentials are the first delay and the most predictable. Sandbox access, certificates, a test account with realistic data, an allowed list entry for our address: each is a request to somebody else's organisation and each moves at their pace rather than ours. Gateway and regulator style counterparties add an approval step with documents attached, which is a queue rather than a task.

Sandbox parity is the second. A test environment carrying twelve rows of sample data proves the shape of a message and nothing about its behaviour. Real duplicates, real special characters in a customer name, a purchase order with forty lines: these are what expose the design, and getting them into a test environment is often the longest single item on the plan.

Documentation describing a version that is no longer running is the third, and it is common enough to plan around rather than complain about. We call the live endpoint in the first week rather than trusting the specification, which sounds obvious and gets skipped constantly. Where a payment gateway or a regulator sits at the far end, their approval is a dated milestone on our plan with a named person against it. The committed date goes in once credentials exist, and not one week before.

  • Six to twelve weeks reported for a focused single scope go live, and for FBR integration
  • Credentials, certificates and sandbox access requested in week one as a named dependency
  • Test data made to resemble production, including duplicates and awkward characters
  • The live endpoint tested early rather than the published specification alone
  • A committed date given after access exists rather than in the proposal
03

An integration platform or code you own

There are two honest ways to build an integration layer. Licence a platform and configure flows inside it, or write the integration as software you hold in your own repository. Both work. They fail differently, which is the part worth thinking about before the invoice arrives.

A platform buys you connectors, a graphical flow builder, retry and queueing already implemented, and an operations console somebody who is not a developer can read. For a business running a familiar set of systems, that is a genuinely good trade. The costs are equally concrete. The licence is usually billed in a foreign currency, which for a Karachi business is an exchange rate exposure repeated every year. Connectors cover the common case and stop at the edge of it, so the awkward flow ends up in a scripting box inside the platform where nobody can test or version it properly. Skills are narrower here than for general development, and the day the person who built the flows leaves is a day worth imagining in advance.

Code you own inverts that. No licence, no renewal in dollars, ordinary version control, ordinary tests, and any competent developer can read it. What you take on is the plumbing the platform provided: retry policy, idempotency, a queue, a dead letter path, monitoring, and an operations view for whoever watches it at seven in the morning. That is real work and it should appear in the estimate rather than in an incident three months later.

The deciding questions are usually operational rather than technical. Who runs this at eight on a Sunday evening when a file has not arrived. Which team can change a mapping without a release. What happens to the flows if the licence is not renewed. How much of the estate is standard products against how much is a system somebody wrote here in 2009. We have built both, and we have moved work off a platform when the licence renewal cost more than the flows were worth. The recommendation is written down with a five year cost line covering licence, people and the exit.

  • A licensed platform where the estate is standard products and non developers must operate it
  • Code you own where flows are unusual, volumes are high or a foreign currency licence is unwelcome
  • Licence renewals costed across five years, including exchange rate exposure
  • Retry, idempotency, queueing and monitoring costed explicitly wherever they are hand built
  • An exit route written down before the first flow is committed to either approach
How we deliver

Delivering API & integration development

A build is planned one phase at a time. These six steps run inside each phase rather than once across the whole product, which is how the second phase gets planned on measured pace instead of a guess.

  1. 01

    Discover

    What does a user in this role need to do, and what does success look like as a recorded outcome. We also ask which existing systems hold the data, because that usually decides the architecture.

  2. 02

    Blueprint

    Tenancy model, identity provider, data residency and the shape of externally visible identifiers get decided now, in week one, because all four are cheap here and disruptive after the first paying customer.

  3. 03

    Build

    The deployment pipeline goes in before there is anything worth deploying. Then sprints, with each one ending in a working release on a real environment rather than a demonstration on a laptop.

  4. 04

    Test

    Coverage concentrates where money, permissions and data integrity live, plus a regression suite that runs on every change. Each production defect earns a permanent test, so the suite ends up shaped by real failures.

  5. 05

    Go live

    Release to production through the same pipeline every other build used, behind a feature flag where the change is risky. Request tracing and alerting on user visible symptoms are on before the first user arrives.

  6. 06

    Run

    Dependency updates, certificate renewals and platform deprecations are handled on a cadence, not when something breaks. Hosting cost is reviewed quarterly and attributed to the features generating it.

Working together

The contract outlives the project

An integration is a relationship between two systems that will both change without consulting each other. The specification is what makes that survivable: a published contract, a version, a deprecation policy and a record of who is consuming what. Teams treating those as documentation overhead end up unable to change anything at all, because every alteration carries an unknown blast radius and the safest available action is always to do nothing.

We build interfaces to be operated rather than merely delivered. That means an owner per flow, monitoring that shows lag and correctness rather than only availability, retries that are safe to repeat, and a runbook for the failure that arrives at an inconvenient hour. The aim is that somebody who did not build the interface can diagnose it, which is a low bar that a surprising proportion of production integrations do not clear.

Credentials

Accreditations behind Development & SaaS

Custom software runs on somebody else's platform, so what we are accredited to build and run on matters as much as the code itself.

Oracle

Partner

Applications built over Oracle schemas get read through views and stored procedures rather than direct table access, and we integrate with E-Business Suite and Fusion through their published REST services.

Microsoft

Partner

Azure for hosting, Entra ID when a corporate customer makes single sign on a condition of purchase, and Azure SQL or SQL Server where the data belongs in a managed relational engine.

Google

Partner

Container workloads on Google Cloud with a chosen processing region, Workspace sign in for internal tools, and Firebase where a mobile application needs push notification and offline handling.

FBR digital invoicing

Compliant integrations

Billing and point of sale modules we write submit to the FBR system directly. Sandbox tokens first, then production credentials, with failed submissions queued and visible rather than swallowed by a retry loop.

HIPAA

Compliant practices

When an application we build holds protected health information, we are the business associate and sign accordingly. Role based access, encryption in transit and at rest, and audit logs are part of the build.

Client words

What Development & SaaS clients say

Comments from people who run development & saas systems day to day.

  • They wrote our requirement documentation knowing it had to survive a tender committee, and they were direct when one of our requirements could only be met by a single supplier. We would not have caught that ourselves. The audit trail design has since been through a full review without a finding.
    IT Director Public sector authority
  • Our first concern with FBR integration was simple: what happens to the tills when the line drops. They built the queueing and retry before anything else and demonstrated it by pulling the connection in front of us. Trading carried on, and the invoices went up when the link came back.
    Operations Manager Retail chain, Pakistan
  • Every vendor we spoke to said they could handle style, colour and size. This team asked to see our order book first, then told us which of the shortlisted platforms would need thousands of item codes to do it. That one piece of advice probably saved us a year.
    General Manager Textile exporter
Questions

Questions about API & integration development

Interfaces are priced individually. The nearest published market anchor is adding e-invoicing to an existing POS or ERP at PKR 150,000 to 400,000, which is about the size of one documented single direction flow. Broader integration work sits against the custom web application band of PKR 200,000 to 1,000,000 and upwards. Hourly, full stack rates run PKR 3,500 to 8,000. We quote after discovery.

Reported timelines give six to twelve weeks for a focused single scope go live, and FBR integration is published in the same band. Several flows with a service layer and monitoring move into the three to six month range. Waiting for credentials and getting realistic data into a sandbox usually take longer than writing the code, so both go on the plan in week one.

Yes, and the integration is the smaller half of that job. A merchant account, credentials and a sandbox come first, and the provider sets that timetable rather than us. After go live the work is reconciliation: what the gateway says settled, what the order says was paid and what the ledger shows, agreeing every day. We build the report that makes a mismatch visible before a customer reports it.

REST is the usual style for new work: ordinary web requests, JSON, and a specification published in OpenAPI so a consumer can generate a client from it. SOAP is older, heavier and built around a formal contract in XML, and a great deal of banking and ERP software still speaks it. Neither is better in the abstract. The system at the far end decides, and it generally decides for you.

It is quick and it is the decision organisations regret most. Direct access bypasses the validation that keeps your ledger consistent, ties an outside party to your table structure so you can no longer change it, and leaves no record of who read what. An interface with authentication, a contract and a log costs more this month and far less over the life of the system.

Hosting, monitoring, and time. Interfaces are operated for years and built in weeks, so budget for certificate renewals, credential rotation, changes at the far end, and somebody named who answers when the reconciliation does not balance. We hand over an error runbook and a monitoring dashboard so that person can be yours rather than ours if you prefer.

More in Development & SaaS

More Development & SaaS services

Software engineering

SaaS product development

Multi-tenant products built from discovery through to a released, billable first version.

Open service page → Software engineering

Custom application development

Internal web and mobile applications built against the systems you already run.

Open service page → Software engineering

Secure environment engineering

Application environments built to a security baseline: identity, secrets, least privilege, audit.

Open service page → Software engineering

QA, testing & release management

Test coverage, regression suites and release control so upgrades stop being an event to fear.

Open service page →

How many of your interfaces are documented?

Tell us what you run today and where api & integration development is causing you trouble. The first conversation is a consultation rather than a pitch.

Book a consultation All development & saas