REST connections
Pull products from your own REST API with simple authentication, map the fields once and refresh on a schedule.
A connection in the Connections tab pulls products from a REST endpoint you control. It is the honest first version of connecting a live API: generic REST, mapped once and refreshed on a schedule. If your ERP, product data system or stock system can answer a GET request with JSON, it can feed the catalogue, and you never have to remember to re-export a CSV.
Setting up a connection
- Name and base URL for the API.
- Authentication: bearer token, basic auth or a custom header whose name you choose. Credentials are stored encrypted and are never shown again after you save them.
- Endpoint path and a pagination preset (page and limit, a cursor field or offset).
- A test fetch button that shows the first item returned as JSON so you can confirm the shape.
- A field map from JSON path to schema field, with the same synonym based automatic mapping used on import.
Pagination
Almost no real catalogue endpoint returns everything in one response, and almost every API paginates differently, so the mode is yours to set.
| Mode | What Kabaido sends |
|---|---|
| None | One request. Right for a small feed that genuinely returns the whole list. |
| Page | A page number parameter, starting from whatever your API counts from, with an optional page size parameter. |
| Offset | A row offset parameter, advancing by the page size each time, with an optional limit parameter. |
An items path tells Kabaido where the array lives inside the response, written with dots: data.products, result.items, or nothing at all when the response is the array itself. Paging stops as soon as a page comes back empty.
Testing before you trust it
The test fetch is worth using properly. It requests the first page and shows you the first record exactly as your API returned it, which is how you find out that the price is nested two levels deeper than you thought, or that the field you wanted is a string where you expected a number. Map against what you can see rather than against the documentation.
How records merge
Records are upserted by their external id, the identifier your own system gives them, so re-running a connection updates existing products rather than duplicating them. That identifier is the thing to get right at setup: without it, a second sync has no way of knowing it has met a product before.
Values are coerced against your schema exactly as they are on a CSV import, so a field declared as a dimension in millimetres normalises whatever your API gives it, and a value that will not coerce is left empty rather than written wrong.
Running and watching
Choose a manual or a daily schedule. Each connection carries a status card showing the last run, how many items it synced and any error, so a token that expired shows up as a message rather than as a catalogue that quietly stopped changing. Each page request is given 20 seconds; a single sync fetches at most 200 pages, which is a guard against a source API whose pagination never terminates.
Provider specific presets are on the roadmap, not pretend buttons. Today every connection is configured as generic REST. If your system pushes rather than answers, the products API takes a bulk upsert the other way round.