Customer connections
Pull customers from your CRM or ERP over REST, mapped once and refreshed on a schedule.
Your customer list almost certainly already exists somewhere: in a CRM, in an ERP, in the accounts package that raises the invoices. A customer connection reads it from there over HTTP rather than asking you to keep a second copy in step by hand. It is the exact counterpart of the product connections in Catalogue, and it is configured the same way, in Settings, then Integrations.
What the endpoint has to do
One GET request, returning JSON, containing an array of customer records. That is the whole contract. It does not have to be an API built for Kabaido; a read-only report endpoint on your own server is a perfectly good source.
- The base URL and the endpoint path, which are joined into one address.
- Authentication: a bearer token, HTTP basic, or a custom header whose name you choose (x-api-key by default). The credential is encrypted at rest and never shown again after you save it.
- An optional root path, written with dots, pointing at the array inside the response: data.items, result.customers, whatever your system nests it under. Leave it empty when the response is the array itself.
- A field map from the source record to company, email, phone and external id. Each of those is a dotted path too, so a nested address like billing.contact.email is fine.
- A schedule: daily, or manual if you would rather run it yourself.
Only the company mapping is required. A record whose company field resolves to nothing is skipped rather than imported as a blank customer.
How records merge
Matching is what stops a nightly sync from turning one customer into thirty. Each incoming record is matched against your existing customers in two passes.
- By external id, if you mapped one. This is the strongest match: it is your own system's identifier, stored against the customer, and it survives a company being renamed.
- By email domain, derived from the mapped email. Two people at the same company share a domain, so this catches the common case where your source has no stable id to give.
A match updates the existing customer. No match creates one, and if the record carried an email or a phone number, that becomes the customer's primary contact straight away, so the record is usable rather than a bare company name.
Customer connections never delete. A record that disappears from your source system stays in Kabaido until you remove it, because a source system going quiet for a night is far more likely than thirty customers ceasing to exist.
Running and watching
A daily connection is run by the platform's own scheduled job; a manual one runs only when you press the button in Settings. Either way the connection records when it last ran and what went wrong if anything did, so a credential that expired shows up as a message against the connection rather than as customers that quietly stopped arriving. Each request is given 20 seconds to respond before it is abandoned.
A source that answers with something other than 200, or with JSON that is not an array where the root path says it should be, fails the run and leaves your existing customers untouched.
The push alternative
A pull connection needs your system to be reachable from the internet. When it is not, the same merge logic is available the other way round: an inbound endpoint accepts customer records posted to Kabaido, matched and upserted by exactly the rules above. Pick whichever direction your network allows.