Your agents are running, cards are moving, records are landing in collections. All of it sits on the board, and that is fine.
But your company runs other systems too. Your CRM wants to know about a new client request, your accounting software wants to hear about a closed deal, a small service you wrote yourself wants to learn that a report is ready.
Instead of each of them checking, you can tell them what happened.
What an outgoing connection does
An outgoing connection sends a message to an address you choose whenever something happens in Orbi. When a card opens, a record lands in a collection or a run finishes, your own system learns about it immediately and does its own job.
This is the outward direction. The reverse exists too, an event from outside starting a flow in Orbi, but that is a separate mechanism.
Twenty-six events
The events you can subscribe to fall into six groups.
On the card side there is opening, a state change, assignment, an update, deletion, a comment, a checklist step and an attachment. In collections, creating, updating and deleting a record. In files, a file being created and a new version arriving. In runs, task and flow runs starting and finishing. In membership, joining, leaving and a role change. And on the credit side, credits running low and running out.
You pick as many as you want. Subscribing to everything looks safe at first and leaves you filtering out events you will never process on the receiving side.
Four events keep their old names in the list. Those are names from the first release and they keep working, because an integration somebody built should not go quiet just because we renamed something.
Narrowing matters more than what you send
Adding a connection asks for three things. The address, the events and the narrowing.
The narrowing is optional and it is the part that earns its keep. You can send only the cards of certain projects, only the records of certain collections, or only the changes made by people, or only those made by agents.
That last option is more useful than it sounds. A "only what agents wrote" filter streams automatically produced records into your own system while leaving human entries out. Or the reverse, you listen only to human moves and take none of the agents' noise.
With no box ticked, everything is sent.
Verifying the request really came from Orbi
A secret is shown the moment you save, and it is never shown again. Save it, because it is what you will verify with.
Every request carries a signature, produced from the secret over the timestamp joined with the body. On the receiving side you run the same calculation and compare.
Sign the body in its raw form, because a body parsed into JSON and serialised again has different field order and whitespace, and the signature will not match. Second, reject the request if the timestamp is too old, otherwise a captured old request can be replayed at you.
The headers carry one more field you have to use, and skipping it costs you later. The event's id is what stops you from processing the same event twice. When a delivery is re-sent the event id does not change, so deduplication on your side keeps working.
Rotating the secret does not stop the flow
When you rotate the secret, the old one stays valid for another twenty-four hours, and during that window every request arrives with two signatures.
It looks like a small detail and it saves a morning. You update your receiving system without rushing, and no event is dropped in between.
The delivery log
Clicking an endpoint opens its panel, and the subscribed events, the delivery log and every action live there.
The log shows the recent deliveries. The status, which attempt it was, the code the receiver returned and how long the request took are all on the row. Open the detail and you see the body that was sent and the receiver's response exactly as they were.
The answer to "why did it not arrive" is usually right there. The thing that wastes the most time when building an integration is not knowing whether the request went out at all.
A failure is not lost
If the receiver does not return a 2xx, the request is retried three more times. After one minute, five minutes and thirty minutes.
If all of them fail the delivery stays marked failed and you can send it by hand. Resend for a single row, resend failed for all of them.
There is a test button, and the request it sends carries no real event name. That is deliberate, because a test request should not be mistaken for the real thing by your automation.
A dead endpoint does not get hammered for hours
After five consecutive failures the connection pauses itself and the admins get a notification.
This is not a deletion. The events and narrowings you chose stay in place, and once you fix the address you reopen it and it carries on from where it stopped.
Without the pause we would keep sending requests to a dead address for hours and you would never find out. An integration that quietly stopped working is more dangerous than one that was never built.
Four limits
At most sixty requests a minute go to one address. If a bulk operation produces more events the rest carry over to the next minute rather than being dropped.
Internal network addresses are refused. Redirects are not followed, so write the address in its final form. A request that gets no response in ten seconds counts as failed.
The body can grow without breaking
New fields can be added to the body and that does not count as a breaking change. On the receiving side, ignoring fields you do not recognise is enough.
If a field has to be removed or its meaning changed, the version number goes up and the old version keeps being sent for a while. Your integration does not break one morning without warning.
Where to start
Start with a single event. A card changing state or a record landing in a collection is plenty.
On the receiving side, make verifying the signature the first thing you do and recording the event id the second, so the same event is never processed twice. An integration built without those two runs into trouble on its first busy day.
Then read the delivery log. After a few real events have gone through you will see which fields you actually use, and widen the subscription accordingly.
The event list, a signature verification example and the limits are covered in Outgoing webhooks in the help center. To start work in Orbi from an event coming the other way, see Flows.
If you want to try it, you can open a free account and set up your first connection.