Webvelopment
Development

API Integrations

Connect websites, CRM and operational tools through scoped API integrations with field ownership, permissions, duplicate handling and visible delivery failures.

Let’s talk

The problem we help solve

When a website enquiry needs to reach sales, someone has to know that it arrived, contains the right information and has not appeared twice. The same questions apply when orders, stock or other operational records move between tools.

We help you define and build that handover through an API: the interface a system makes available to other software. Together, we decide what triggers the transfer, which fields move and what staff should do when a record is missing, repeated or rejected. That gives your team something they can check in their everyday work.

The connection, made visible

Every handover needs a way back.

An illustrative planning pattern. Your actual systems and rules determine the implementation.

Normal delivery

  1. Website or source
  2. Validate & record
  3. Map & deliver
  4. Receiving system

Keep the source reference and make the receiving result visible.

When something fails

  1. Keep the original event
  2. Show a pending state
  3. Retry the same reference
  4. Review the exception

A lost acknowledgement must not silently become a duplicate record. Assign recovery to an authorised owner.

What we can deliver

Depending on the systems and workflow, the work can include:

  • System and data-flow mapping: where a record starts, where it goes and which direction changes travel.
  • Field and identifier design: how the receiving tool recognises the record and interprets each value.
  • Authenticated integration development using approved access and permissions.
  • Retry and exception handling, including cases that need a person to resolve them.
  • Monitoring and support handover, with responsibilities agreed for the connection after launch.

We agree which of these you need before estimating implementation. Bring a non-sensitive example of the record you want to move and show us what a correct result looks like in the receiving tool. This is often more useful than starting with a list of product names.

Technical leadership

Our technical approach draws on practical PHP development, enterprise integration and digital strategy experience. Willan Theunissen’s professional background explains the experience behind this work, including record mapping, lead intake and routing. For your project, we use that background to ask practical questions about who uses the records and who will maintain the connection.

How we approach the work

We start with one event and follow it through both systems. Which fields are required? Where should a correction be made? If both tools can change a value, which change should take precedence?

Your business and system owners help answer those questions. We then map the fields, test representative records and agree what happens when either system is unavailable. During review, your team checks the record in the receiving tool as well as the technical result. A sales person, for example, should be able to recognise the enquiry and see the information needed to act on it.

Who this is for

This service is for teams connecting websites, CRM, commerce and operational tools. It is useful when the task involves more than transferring a value: a record needs to reach the right destination, retain its meaning and be recoverable if delivery fails.

You may already have a connection that needs assessment, or you may be planning a new workflow. In either case, show us the current handover and the part your team cannot confidently check or manage.

Boundaries to agree early

Access permissions, API limits, subscription requirements and supplier changes affect what can be built and operated. We need to review the actual interface and account access before confirming a connection; a product’s API may not expose the fields or actions your workflow requires.

Agree who manages each account, who can approve access and who takes responsibility for failed records. Continuing maintenance and monitoring also need an agreed scope. They should not be assumed to come with the initial build.

Questions before we start

A few useful answers before you decide.

Can sales leads enter our CRM?
Yes, where an approved API and suitable permissions exist. We first map required fields, record ownership, duplicates and consent context. Bring an example enquiry and show us where a sales colleague expects to find it in the CRM.
What do you need from us?
Tell us which event should move between which systems and who owns each account. Include a non-sensitive sample and explain what should happen to it. Share public documentation links where available; arrange credentials through an agreed secure channel.

Specify the handover, not just the connection

Imagine a proposed workflow in which an approved website enquiry enters a sales system. The record needs the right fields, a way to recognise an existing contact and a clear destination for failed deliveries. Your team also needs to know where to correct an error after the transfer.

For example, an existing contact might submit a second, different enquiry. The contact may be the same, but the new request still needs attention. Repeating delivery of the first enquiry is a different case. We would agree and test the expected result for each, so a duplicate rule does not accidentally hide new work.

A useful first implementation can cover one record type and test a valid record, a duplicate, an invalid value and an unavailable destination. The person reviewing the work should be able to inspect each result in the receiving system. This is an example of a possible workflow; it does not describe a deployed connection or establish a particular platform’s capabilities.

Your team provides approved access, account ownership and available technical documentation. We check the interface and its constraints against the task before confirming what we can build.

Write a delivery contract for one event

A delivery contract is a plain description of what the two systems should do. It should answer these questions:

  • What event starts the transfer, which source record does it refer to and where should it arrive?
  • Which fields must arrive, and what happens if a required value is missing or invalid?
  • Should a repeated event update the existing record, create another one or be rejected?
  • How does an authorised person find a failed delivery, check the receiving system and resolve it without exposing private data?

Use this description during testing and handover. It gives the developer and the people using the systems the same expected results to check.

Further integration questions

A few useful answers before you decide.

Can any two tools with APIs be connected?
Not necessarily in the way you need. We assess permissions, available actions, field structures and operating limits against the task. A requirement may need a different workflow or a manual step. The actual interfaces matter more than the fact that both products advertise an API.
Who decides which system owns a record?
The people responsible for the business process and the systems need to agree. If both tools can edit the same field, decide where corrections belong and how conflicts should be resolved. We can help make the choices clear, then implement the agreed rules.
How should duplicate records be handled?
Start by distinguishing a repeated delivery, a correction and a new request from an existing contact. These can look similar while needing different treatment. Your team approves the matching rule and resulting action. We test similar but distinct examples so legitimate enquiries or changes are not discarded.
What happens when delivery fails?
We agree how staff will see a failure, when a retry is appropriate and who can resolve the record. Some rejections need a correction in the sending or receiving system. The scope should include that recovery route and an honest status for the person relying on delivery.
Can you assess an integration before the full project?
Yes. A feasibility stage can review authorised documentation and test a specific action in an appropriate environment. We explain what the test establishes and what still needs checking. A demonstration account may have different permissions from the live account, and it may not reveal problems in existing records.
What belongs in the test plan?
Include normal records, missing values, rejected permissions, duplicates and an interrupted connection where relevant. Both system owners should agree the expected results. Use synthetic or appropriately protected data, then inspect the receiving records and recovery behaviour alongside the sending application’s response.
What must remain documented after handover?
Keep the field map, account ownership, credential management arrangements, known limits and instructions for handling failed records. Identify the subscriptions and interfaces the connection depends on. Name the people responsible for maintenance and monitoring, with those services scoped separately where required.

Prepare your next conversation

Send us the event you want to transfer, the two systems involved and a non-sensitive example of the expected result. Tell us who manages the accounts and who will check the records. Public documentation links are helpful; credentials should follow an agreed secure channel.

Apply routing to distributor enquiries · Scope the workflow around the connection

Discuss this api integrations brief.

Enterprise data orchestration · Ecommerce accounting integrations · 03 integrations.

Plan the scope and estimate

Use the API & Systems Integration Estimator to describe the interfaces, records and direction of transfer. It separates known labour from work and supplier costs that need a custom quote. Bring unresolved access or recovery questions into the estimate discussion rather than treating them as included work.

Choose a concrete integration workflow

Connect website forms to Zoho CRM, assess WooCommerce and Sage, plan Shopify accounting records or publish vehicle stock feeds. Each starts with the actual product and interface, then defines record ownership, duplicate handling and recovery.

Inspect our worked CRM field map and retry example before building an integration budget.

Keep exploring

Keep the right things connected.

Our expertise

Bespoke Development

Plan business software around the work people need to do: choose an application, eCommerce change, PHP update or integration, with a clear first release.

How we work

Clear decisions. Reviewable progress.

How Webvelopment scopes, designs, builds and hands over digital work with clear ownership at every stage.

Let’s move things forward

Start a conversation

Tell us what you are working towards. We’ll help you find a practical next step.

Let’s talk