Docs / Getting started
What this platform is
A place to build and run the integrations a business needs — the small, long-lived programs that move a record from one system into another, react to something that happened, and report on what they did.
You already know how to write those. The reason to write them here is that the
work around them is what actually costs: the credential that has to be
refreshed, the far end that answers 429 for twenty minutes at month end, the
nightly job that was interrupted at record nine thousand, the question “did this
order ever arrive?” asked three weeks later.
What you build with
Four things, and you will meet all of them in the first hour.
| What it is | |
|---|---|
| Environment | A sandbox or a production installation of your integrations. The two are sealed off from each other — separate configuration, separate credentials, separate data — and nothing in one can reach the other. You build in sandbox and promote to production. |
| Connection | Where another system lives and who you are to it: an address and a credential. Scripts never see the credential. |
| Function | One operation, configured once and called by name: create a contact, fetch yesterday’s orders, write the confirmation mail. Your own vocabulary, not HTTP. |
| Script | The business logic, in JS. It reads what triggered it, calls functions, decides things, and answers. |
A script is started by a trigger: a webhook arriving on one of your endpoints, a schedule coming due, a message landing in a watched mailbox, a synchronous call waiting for an answer, or something in the environment going wrong. Every start becomes a run — a record of what came in, what was called, what was logged, and what came out.
What makes it different
Two things. Everything else on this platform exists to support them.
A call is configured, not coded
The instinct in any other tool is to write the request: the URL, the headers, the token, the retry loop, the paging. Here that belongs to the configuration, once, and your script says what it wants:
const contact = FindContact({ email: input.event.body.customer });That call has a connection behind it, a credential the script cannot read, retries on the answers worth asking again for, a real pause when the far end says not now, and a recorded request and response on the run. None of it is in your code, and none of it is yours to maintain. When the far end changes its address, moves to a new authentication scheme, or starts rate-limiting, the configuration changes and the scripts do not.
It also means the call reads as the thing it fetches. Whoever configured
FindContact decided which statuses are an answer and what the answer is — so
there is no envelope to unwrap and no status to check. See
Connections and functions.
A run is saved as it goes
Every step a run takes is written down before the next one starts. That is not an implementation detail you can ignore — three things you would otherwise have to build follow from it:
- An interruption is not a restart. A restart, a deployment, a machine going away: the run continues on another one, from where it stopped. It does not begin again, and it does not repeat a call it already made.
- Waiting is free. A far end that says “come back in twenty minutes” gets exactly that: the run is put away, nothing is held open, and it wakes up and carries on. The same is true of a wait you ask for yourself.
- Afterwards, you can read what happened. Not a log line somebody remembered to write — the payload that arrived, every call that went out, the answers that came back, and the value the run produced.
What this is not
- Not a data warehouse. Staged data is working storage for a job, not a place to keep history.
- Not a place for heavy computation. Runs are bounded on purpose. Work that is genuinely large belongs in batches the platform walks for you, not in a loop in a script.
- Not a general web application host. There is no UI to build here and no server to run; there are triggers, scripts, and answers.
- Not a replacement for the far end’s own rules. The platform will not let you send the same request twice by accident, but it cannot make a system that charges a card twice safe. Where the far end demands it, your script still needs to be written so that doing it twice is harmless.
Where to go next
If you want to see it work, go to Your first automation. If you want to know the rules before you write anything, start with The language.