CRM software integration built around the data you actually have
Apefo Ltd, trading as JNET.support, connects the systems you already pay for. A website form that writes a proper CRM record. An inbox that turns a purchase order into a deal. A finance tool that stops sales chasing an invoice that has already been paid.
The demo version of any integration works. The one that matters is running eight months later, after someone renamed a picklist value, a supplier started sending dates as DD/MM/YY, and forty records piled up in a queue nobody opens.
How two systems get connected
There are seven realistic ways to move a record from system A to system B. Which one you get is usually decided by what the vendor exposes.
| Method | Right choice when | Cost in reliability | How it fails | Timing |
|---|---|---|---|---|
| MethodREST API | Right choice whenBoth sides publish a documented API. The default for anything non-trivial. | Cost in reliabilityLow, until a version is deprecated or rate limits tighten. | How it fails401 after a token rotation; 429 when a bulk import fires 2,000 calls in a minute; a field dropped in a new version. | TimingReal-time. |
| MethodWebhook | Right choice whenSystem A pushes an event the CRM must react to in seconds. | Cost in reliabilityLow for delivery, poor for durability unless you store the event yourself. | How it failsYour endpoint is down 90 seconds during a deploy and the event is gone. Many vendors never retry. Duplicates are normal. | TimingReal-time. |
| MethodNative connector | Right choice whenBoth vendors ship an official integration and your mapping matches their assumptions. | Cost in reliabilityVery low maintenance, very low flexibility. | How it failsStops at the edge case: a custom field, a second pipeline, a record type it was never built for. | TimingReal-time, or a vendor schedule. |
| MethodiPaaS middleware | Right choice whenSeveral systems, branching logic, and a non-developer needs to see what is happening. | Cost in reliabilityModerate. A per-task cost, and a third party whose outages you cannot fix. | How it failsTask limits hit mid-month; a scenario disabled after repeated errors; drift between test and live. | TimingTriggers real-time, polling batched. |
| MethodScheduled CSV | Right choice whenNo API, but a reliable scheduled export. Common with older accounting, payroll and ERP. | Cost in reliabilityHigh. Naming, delimiters, encoding and header rows are all fragile. | How it failsA supplier adds a column in position three and every field after it lands in the wrong place. Nothing errors. | TimingNightly; hourly at best. |
| MethodEmail parsing | Right choice whenThe only machine-readable output is an email or PDF attachment. | Cost in reliabilityVery high. You are parsing a document built for a human. | How it failsThe template changes. Extraction still runs, still reports success, and writes empty or shifted values. | TimingAs reliable as the template. |
| MethodDirect database access | Right choice whenYou own both systems and need volume the API cannot carry. | Cost in reliabilityLow latency, large blast radius. You bypass the application's own validation. | How it failsSkipping application logic leaves the cache, audit trail or search index inconsistent. Schema changes on upgrade. | TimingYour choice. |
CSV and email parsing are last resorts, and we still build them, because no business chooses whether its 1998-vintage stock system has an API. Those routes get validation an API does not need: column-position checks, a row count against the previous run, and a hard stop rather than a partial import.
Mapping fields between systems
The real argument here is rarely technical. Two systems disagree about what a word means.
Take company name. In the CRM it is the trading name a salesperson typed. In accounting it is the registered legal entity, because that is what goes on an invoice. "Jones Roofing" and "J. Jones & Sons Ltd" are one customer, and no string comparison will say so. A decision settles it. One system becomes authoritative, or both are kept with a link between them.
- Free text into a picklistThe form has an open "how did you hear about us" box; the CRM has nine dropdown values. Anything unmatched goes to "Other", with the original text kept in a notes field. Values are never created automatically. Automatic creation is how a dropdown ends up with a few hundred near-identical entries.
- DatesNormalised to ISO 8601 on the way in. The damaging cases are
03/04/2026from a UK versus a US source, and timestamps with no timezone. Those are treated as Europe/London and flagged for a person. - Phone numbersStored in E.164.
01632 960123gets+44; anything already starting+is left alone; an unfamiliar length with no country code is queued rather than mangled. - Required here, optional thereA predictable cause of failed writes, because the two schemas were designed by different people for different jobs. If the CRM demands an account owner and the form cannot know one, the mapping needs a default owner or a routing rule.
Validation runs before the write: required fields, types, formats, and any business rule we are given, such as a rule that a deal cannot be created against a company that does not exist yet. A failing record is never partially written. It goes to the queue whole, with the rule it broke and the payload attached.
Stopping duplicate records
The matching key decides everything downstream. Get it wrong and you create a second Acme Ltd every Tuesday, or overwrite a real customer with someone else's data.
Email alone fails both ways. Shared mailboxes put four people at one company under info@. Personal addresses make one human appear twice. People change jobs and take the address with them.
Preference order starts with an external ID either system already carries, such as a customer number, a Companies House number or a Stripe ID. After that comes a normalised composite, either lowercased email plus company domain, or company name plus postcode. Domain beats name for organisations, once free mail providers are excluded.
A near-match does not merge. It creates the record with a possible-duplicate flag linking to the candidate, or waits in the queue for a person. A human decides, because a merge is very hard to reverse. Activity history and field-level provenance get entangled or lost. A duplicate costs a minute of cleanup. A wrong merge can destroy a customer's history for good.
When a sync fails
This is the part that gets skipped, and it decides whether the integration is still trusted a year in.
Transient failures retry on a backing-off schedule of 30 seconds, 2 minutes, 10 minutes, 1 hour and 6 hours. Timeouts, 429s and 500s from the far end all qualify. Five attempts spread across roughly seven hours covers most vendor outages and overnight maintenance. Where a vendor sends Retry-After, we honour it rather than guessing. That schedule is for scheduled and batch syncs, where nobody is waiting. Inside an interactive build the intervals are much tighter and the item queues sooner, which is why the enquiry build on the automation page retries at 1, 5 and 25 minutes instead.
Expired tokens sit on the boundary and are worth stating precisely. An expired access token whose refresh flow succeeds is transient, and the retry runs against the new token. A refresh that fails, or a credential that has been revoked or had its scopes changed, is permanent. It alerts immediately and that integration pauses, exactly as any other 401 does.
Permanent failures are not retried at all. That covers a validation error, a missing required field, a record referencing a deleted parent, and a 403. Retrying produces the same error five times and delays anyone finding out.
Both end in one queue, and the queue is a place a named person opens, not a log file. Each entry holds the payload as received, the target system and operation, the error returned, the timestamp and the retry history. Entries are kept 30 days by default, longer where an audit trail is wanted.
Replay is the point of it. Once the cause is fixed, whether that is a picklist value added, an owner assigned or a credential rotated, entries re-run against the current mapping, singly or in bulk, in original order where sequence matters. Replaying a "deal updated" before the "deal created" it depends on just fails again. Anything failing twice is escalated to a person.
Two things are agreed before go-live, because they are business decisions: whether a stuck record blocks the ones behind it, and who owns the queue. An unowned queue grows to a few hundred items and becomes wallpaper.
Monitoring and who gets told
A silent integration is not necessarily a working one. Silence and success look identical from outside, so monitoring watches for absence as much as for errors.
- Throughput against expectation
If the form-to-CRM path normally carries around forty records a week and a whole working day passes with none, that is an alert. It catches a trigger that quietly stopped firing.
- Queue age, not depth
One record stuck six days matters more than thirty that arrived this morning.
- Error rate as a proportion
A few failures in a bulk run are normal. Fifteen per cent of a run failing is a mapping problem that started recently.
- Credential expiry
OAuth refresh tokens and API keys have end dates, flagged ahead, because the alternative is discovering the expiry through a failed sync.
- Missing completions
A nightly import that never started produces no error to alert on. The check is for the absence of a success by a given time.
Alerts name the integration, the direction, the record count and the error, and reach a named person with a named backup on a channel they watch. "Sync error" wastes everyone's time. An integration also needs somewhere always-on to run; for our own work that host sits with our sister brand YNVAR.
Of all of these, the volume alert is the one that has earned its place in our own systems. Errors announce themselves, so they get built for. An absence announces nothing, which is why the check for it is the easiest one to leave out.
When there is no API
Some systems will not open up. Three options remain, each with a real limit.
A scheduled export is the best of them. A CSV or XML dropped to SFTP, a shared drive or an inbox is workable. The limits are latency, and that a full-file export gives current state with no record of what changed, so the receiving side diffs against the previous run. Report scheduling is the version non-technical staff can set up themselves, provided the layout is frozen and someone owns the rule that it must not be edited.
Screen-scraping and browser automation exist, and so does their cost. They break on any UI change, they often conflict with vendor terms, and they need credentials with live access stored somewhere. We build them only where the alternative is genuinely manual re-keying.
The forgotten option is asking. Plenty of vendors have an API that is not on the pricing page, or will enable an export on request. And sometimes the answer is not to build it at all. At eleven records a month through a fragile parser, keying them in by hand is cheaper. Better said at scoping than six months in.
How this differs from process automation
These get treated as one job. They are two, with different definitions of success.
Integration moves data between systems correctly. Is the record complete, in the right format, did it arrive, is it the same customer, and what happened to the ones that failed. Success means the two systems agree.
Automation is what happens once the data is there. Route the enquiry, draft the reply, chase the quote after four days, escalate above a value threshold. Success means the right thing happened without someone remembering to do it.
They stack in that order. Automation built on an integration that duplicates records or drops a field does the wrong thing confidently and at speed, and nobody notices for a fortnight because the automation itself is working perfectly. Fix the plumbing first. If you know which you need, we start there; if not, an AI readiness assessment separates them.