Which part do I need?

Concept 3 · 3:23

Each thing you want to do has a part of Weik.io that does it, such as a transfer for moving files on a timetable or the API gateway for partners who call your systems. The video then shows several parts working together on one invoice flow.

Download the mp4Recorded on 2026.2

What it covers

A map of needs, with the part of Weik.io that answers each one and an example
A transfer that copies invoice PDFs from FTP to a storage bucket on a schedule
An integration that posts each invoice to the ERP's HTTP interface
The API gateway in Weik.io, with keys and call limits for partners
An event channel, a schedule, change tracking and the entity store
A webhook through the gateway into a channel, and transfer run records that start an integration

Commands in this video

This video explains with drawings and types no commands.

Transcript

0:01Every need in this video comes with its Weik.io part,
0:06then those parts work together on one flow.
0:12The left column writes each need in plain words.
0:16Beside each need, the middle column names the Weik.io part made for it.
0:21The right column carries one example through the video.
0:28Every morning, invoice PDFs sit on a partner's FTP server,
0:32and the company wants them in its storage bucket.
0:36The left column calls this need moving files from one system to the other on a timetable.
0:43The part that answers it is a transfer, which takes files in from one place,
0:48then puts them down somewhere else on a schedule.
0:51Nobody writes a route for it.
0:57In the example, the PDFs now have to reach the ERP.
1:01The part is an integration, a folder of Camel files,
1:05the only kind you write Camel for.
1:07Every invoice goes to the ERP over HTTP.
1:11Outside callers need to use an API with their own keys, under call limits.
1:16The API gateway, which your Weik.io installation runs, stands in front of the API,
1:21so callers reach the API only through the gateway.
1:26That key's limit says how often the caller may call.
1:30A key opens one environment only.
1:32The next need is reacting when something happened,
1:35with neither side knowing the other.
1:38The part is a channel, a named topic a project owns.
1:42The integration above publishes into the channel.
1:45A second integration reads it, then reacts.
1:52A schedule answers the need to run a command at set times.
1:56When a database table changes, change tracking publishes its changes as events.
2:02Integrations use the entity store to remember what they have already processed.
2:06The map stays open to more needs.
2:12An API call enters through the gateway,
2:14which stands in front of the integration's HTTP route.
2:19The gateway does the same for any other HTTP service.
2:23A system calls one webhook address, and the call comes in through the gateway.
2:28The channel keeps each call stored.
2:31An integration subscribed to the channel reacts to a stored call as it reacts to any other event.
2:37Every finished run of the transfer publishes a run record.
2:40An integration reading those records starts when the morning's batch lands,
2:44without anyone polling.
2:50A transfer moves files on a schedule, an integration carries data between two systems,
2:56the gateway fronts the APIs, and a channel lets one part react to what another did.
3:02A schedule, change tracking and the entity store cover the rest.
3:07Every integration here deploys into an environment,
3:10and your installation's gateway serves the APIs you deploy there.