Tangensys • Plan, deliver, measure
API integration
Agree which system owns each field and how changes move between tools. Reliable integration includes duplicates, failures and reconciliation.
The work to plan together
A scope shaped around this requirement.
- Integration designScope
- Build and testingReview
- Error handling and alertsCheck
- Be foundSearch, maps and AI answers
- Be chosenClear pages and offers
- EnquiryCall, WhatsApp or form
- Follow-upYour team responds
In short
What does API integration involve?
API integration connects your website or apps with other systems, such as CRMs, payment providers, ERPs, WhatsApp and marketing tools, so data moves automatically.
When API integration is a useful fit
Businesses copying data between tools
Name the source of truth for each field and remove repeated copy-and-paste work.
Stores needing ERP sync
Test stock, order and customer synchronisation against the store’s real fulfilment rules.
Teams automating lead handling
Preserve lead source and ownership while checking what happens if either system is unavailable.
Problems worth addressing first
Use these situations to identify the work that deserves attention before expanding the scope.
- Leads are retyped into the CRM
- Orders and stock are out of sync
- Reports combine data by hand
A practical example
A form submission creates or updates one CRM record, retains its source and alerts the team if the CRM is unavailable. It should not silently disappear.
This is an illustrative scenario to explain the approach, not a claimed client project.
The work we can include
The final quote identifies the deliverables, quantities, approvals and exclusions. Select the work that serves your goal rather than assuming every item is required.
- Integration design
- Build and testing
- Error handling and alerts
- Documentation
Where we usually begin
API availability, credentials, quotas and provider changes are reviewed first. Unsupported systems may require a different integration approach.
Practical detail
A field map and a visible failed-sync queue
An illustrative website-to-CRM integration needs to transfer the right information and make unsuccessful transfers recoverable.
| Part of the work | Example output | How to review it |
|---|---|---|
| Field map | form_email → CRM email; service_choice → interest; source_url → source page | The destination record contains the approved fields and no unnecessary sensitive data. |
| Identity rule | Request ID for events; an agreed matching rule for contacts | Repeating an event does not produce a duplicate lead. |
| Failure queue | Request ID, error type, attempt count and next action | The owner can find an unsuccessful transfer without reading private content in public logs. |
| Reconciliation | Source count, accepted destination count and exceptions | Every test request is accounted for as accepted, rejected or awaiting recovery. |
A working happy-path connection is not the whole sign-off test. Include unavailable APIs, expired access, invalid data and retries in the agreed scope.
Agree the record owner before connecting systems
An API integration must answer which system is authoritative for each record. Without that decision, two applications can overwrite each other or produce inconsistent customer information. Map the fields, direction of movement and business event that triggers the transfer.
A one-way lead transfer and a two-way customer sync are different scopes. Include the rules for matching existing records, handling missing fields and dealing with rejected requests. Provider limits and available access need a current technical review.
Test normal transfers, duplicates, unavailable services and recovery. Keep a record of failed items that an operator can understand and resolve. Sensitive data should move only where required by the agreed process, with access and retention responsibilities reviewed by the client.
Free technical review
Start with a clear scope and a practical next step.
Tell us what you want to improve and share the relevant website or project details. We will review the starting point, recommend a suitable scope and provide a custom quote.
The initial review is free. Delivery, third-party charges and ongoing support are quoted separately.
Process
How the work is delivered
Review the starting point
Review the current setup, examples of the problem and the information needed to agree the work.
Agree scope and sign-off
Discovery covers existing code, users, data and external systems. We turn the main workflow into sign-off checks, then agree milestones and responsibilities.
Deliver and review
Changes are reviewed on a test environment before release. Handover includes agreed documentation, access and a maintenance route; ongoing support is separately defined.
Hand over the next steps
Review the agreed outputs together. Confirm what your team maintains and what needs a separate ongoing arrangement.
What progress should mean
Measures that match the work
Measure records transferred correctly, duplicates prevented and errors resolved. Compare source and destination records during sign-off testing.
A record of delivery
See what was completed, reviewed and still dependent on access or approvals. Project delivery and business results are reported separately.
Clear limits in the data
We explain what can be verified and where a result is only an estimate. Contact clicks, conversations and sales are different actions.
Scope and responsibilities
You keep ownership of your business accounts and approved deliverables under the agreed contract. Any third-party licences, subscriptions or usage fees are identified before you commit.
What should we do if the same customer exists in both systems?
Define the matching rule and conflict owner before the build. A shared identifier may help where supported; names alone can be ambiguous. Decide which fields may be updated and what requires human review. The test set should include duplicate and conflicting records.
What happens when the other API is unavailable?
The agreed failure route records the problem and defines whether to retry, queue or ask for staff action. Retry limits should avoid repeated duplicate writes.
Can every system be connected?
Only where a supported API, export or connector and appropriate access exist. Some systems require a different workflow or cannot support the requested real-time connection.
Which systems can you connect?
Most systems with an API; we confirm in discovery.
How is API integration priced?
We quote against your goals, current setup and agreed scope. The quote separates delivery from third-party costs and ongoing support. You receive a custom quote within 2 working days.
How long does the work take?
The timeline follows the size of the agreed scope, access, content and approvals. We confirm milestones in the quote; a simple change and a full implementation need different schedules.
How will we communicate?
Your point of contact agrees a review rhythm with you. We use email, WhatsApp and scheduled calls, with decisions and scope changes recorded clearly.
What do you need to get started?
Share your current website or system, your main goal and examples of what is not working. We then agree the access and information needed for discovery.
Is everything included in the free review?
No. The free initial review helps define the next step. Detailed research, design, implementation and ongoing support are included only when stated in your quote.
Explore the related services
Let’s agree the right next step.
Tell us your goals and current setup. We’ll recommend a practical starting point and provide a custom quote.
Custom quote within 2 working days