Development Agency
Contact Sign in Get a project quote

Service

API & Integrations

For businesses whose work is split across systems that do not talk to each other, and who need data to move between them reliably, with every transfer recorded, repeatable and visible when it fails.

Get a project quote

The problem

What goes wrong today

Where it usually starts

The business asking for integration work is usually re-keying.

  • Bookings arrive from a channel manager and are typed into the property system; invoices are raised in one place and entered again in the accounting package; orders are exported from the shop every afternoon and imported into the carrier portal by hand; the stock figure on the website is whatever it was at the last upload.
  • Each hand-off is a point where a digit is mistyped, a record is missed or a change made on one side never reaches the other.
  • Someone spends the first hour of every day reconciling, and the person who knows how the export works is the one nobody wants to see go on holiday.

Where it gets harder

Where an integration already exists, it was written quickly, runs on a schedule nobody remembers and fails silently: a property feed that stopped updating three weeks ago, a payment webhook that was received twice and credited twice, an order pushed to the carrier before the address was validated.

  • There is no log that says what was sent, when and what came back, so every dispute with a supplier or a customer becomes an archaeology exercise.
  • The business does not need a new system; it needs the ones it has to exchange data correctly, and to know when they do not.

Scope of the service

What the build covers

An integration project normally covers the mapping between two or more systems, the transport, the error handling and the monitoring. We begin by listing every data flow: what record moves, which direction, what triggers it, what a conflict looks like and who should hear about a failure. Each flow becomes a specification with a field mapping, a source of truth for each field and a rule for what happens when the two sides disagree. The build connects through the interfaces each system publishes, whether a documented API, a feed format, a webhook or a scheduled file exchange. Every outbound call is idempotent, so a retry never creates a duplicate; every inbound event is checked for signature and event identity and handled out of order; every transfer is logged with the request, the response and the outcome, and failures are retried with backoff and then raised to a person.

Where your own systems need an interface, we build the API with authentication, versioning, rate limits and documentation, so partners and your own tools can call it. A monitoring dashboard shows each flow's last success, backlog and recent failures.

When the scope grows

Scoping scenario

An estate agency with three branches wants property records to flow from its agency software to its website and to two portals, viewings booked on the portals to appear in the branch diaries, and completed sales to reach the accounting package once, however many times the notification arrives. The three destinations, the two-way diary flow and the once-only accounting rule make this a project, and the specification names each flow.

Deliberately out of scope

  • Changing the business logic inside the systems being connected, data cleansing beyond the rules agreed for conflicts, and work on systems that publish no interface at all, where we say so plainly rather than screen-scrape

Deliverables

What you receive

  • Discovery notes listing every data flow, its trigger, its source of truth and who handles a failure
  • A written specification per flow with the field mapping, conflict rules and what is left out
  • The integration build with idempotent outbound calls, verified inbound webhooks and retry with backoff
  • A transfer log and monitoring dashboard showing last success, backlog and failures per flow
  • Your own API where scoped, with authentication, versioning, rate limits and documentation
  • A reconciliation run against historical data so both sides agree before go-live
  • Handover material, runbooks for each flow and full ownership of the source code

Process

How a project runs

Each stage maps onto the project view in your client panel. Durations are set in your proposal, never on this page.

  1. Onboarding

    Access to each system's interface, sandbox accounts and documentation; samples of the records that move today and how they are re-keyed.

    Project stage: Onboarding

  2. Planning

    Every flow is listed with its direction, trigger and conflict rule; the field mappings are written into the specification.

    Project stage: Planning

  3. Design

    Flow sequences, error paths and the monitoring dashboard designed; the API surface designed where one is built.

    Project stage: Design

  4. Development

    One flow at a time against sandboxes: transport, mapping, idempotency, logging and retries, then the dashboard.

    Project stage: Development

  5. Client review

    Your team runs real records through each flow in the sandboxes, including duplicates, out-of-order events and deliberate failures.

    Project stage: Client review

  6. Revisions

    Mappings and conflict rules adjusted from the review and re-checked against the specification.

    Project stage: Revisions

  7. Ready for launch

    Live credentials under your control, a reconciliation run on historical data, alerts routed to the named people.

    Project stage: Ready for launch

  8. Delivered

    Flows run in production with monitoring; maintenance continues under its own agreement if taken.

    Project stage: Delivered

Integrations

Commonly integrated

Systems this kind of business usually asks us to connect. Each integration is confirmed during discovery; none is assumed.

  • Property software and portal feeds for listings, viewings and offers
  • Channel managers and booking engines for availability and reservations
  • Payment providers with verified webhooks through the provider-independent payment layer
  • Accounting software for invoices, payments and settlement
  • Carriers and courier platforms for labels, tracking and proof of delivery
  • Customer relationship and marketing platforms for contacts and consent
  • Warehouse, stock and point-of-sale systems

How we would approach it

Worked example

Concept demo

An estate agency with three branches, two portals and one accounting package

The situation

An agency wants property records to flow from its agency software to its website and two portals, viewings booked on the portals to appear in the right branch diary, and completed sales to reach the accounting package exactly once however many times the completion notification arrives.

Why it is a custom build

The custom route is needed because the three destinations have different formats, the diary flow runs in both directions, and the once-only accounting rule must hold under duplicate and out-of-order events.

The scope we would propose

  • An outbound property flow with per-portal field mapping and a change log
  • An inbound viewing flow with branch routing and conflict rules when a slot is already taken
  • A completion flow with event identity checks so a repeated notification is ignored
  • A transfer log for every call
  • A dashboard that shows each portal's last successful update and raises an alert when a flow stalls

Concept demo: a scoping scenario written to show how we would approach the work. It is not a delivered client project.

Pricing

What affects the price

Every proposal is priced on scope. These are the factors that move it most for this kind of build.

  • Number of systems and data flows, and whether each is one-way or two-way
  • Quality of each system's interface and documentation, and whether a sandbox exists
  • Conflict rules and how much reconciliation of historical data is needed
  • Volume and frequency of records, and whether near-real-time transfer is required
  • Whether your own API must be built, and for whom
  • Monitoring, alerting and reporting requirements
  • Security requirements such as credential handling, encryption and audit
  • Hosting choice for the integration layer: your own hosting or ours

Start from a package

  • Software package

    Estate agency package

    Property register, public search, enquiry routing, viewing diary, applicant matching and portal feed output for independent and small multi-branch agencies.

    Custom build

  • Software package

    Short term rental package

    Direct booking, multi-unit calendars, guest verification, scheduled self check-in, cleaner turnaround tasks and owner statements for serviced apartment operators.

    Custom build

  • Software package

    Parcel tracking package

    Consignment tracking with scan events, a phone-based driver scan page, photo and signature proof of delivery, recipient notifications, an exception queue for failed deliveries and shipper imports.

    Custom build

FAQ

Frequently asked questions

Which systems can you connect?

Any system that publishes an interface: an API, a feed format, webhooks or a scheduled file exchange. The sector packages show typical examples, such as portal feeds in the estate agency package, channel managers in the short-term rental package and carrier connections in the parcel tracking package. Where a system publishes nothing, we say so rather than screen-scrape.

What does idempotent mean and why does it matter?

It means an operation can be repeated without changing the result: sending the same order twice creates one order, not two. Networks fail and systems retry, so every outbound call carries an identity and every inbound event is checked against the ones already handled. That is what stops double invoices, double credits and duplicate shipments.

How will we know when an integration fails?

Every transfer is logged with what was sent, what came back and the outcome. Failures are retried with increasing delays and then raised to the people you name, and a dashboard shows each flow's last success and backlog. Silent failure is the problem we are usually asked to remove.

Can you build an API for our own system?

Yes. Where partners, your website or your own tools need to read from or write to a system you own, we build the API with authentication, versioning, rate limits and documentation, and the same logging and monitoring as the other flows.

Who owns the integration code?

You do, along with the logs, runbooks and documentation. The integration layer can run on your hosting or ours, and monitoring and updates continue under the maintenance service if you take it.

Get a project quote for api & integrations software

Answer a few questions about your business, your current systems and what should change. We reply with a clear, competitive proposal.

Get a project quote Discuss a partnership
Get a project quote

Cookies on this site. Strictly necessary cookies keep the site working. Allow first-party analytics so we can see which pages lead to enquiries. No advertising, no third-party trackers, no personal data; you can change this at any time on the cookies page.

Manage preferences