Let the booking tell your other tools
Retyping details between tools fails on busy weeks. What to settle before a webhook replaces it.
Who this guide is for
Studio operators and the developers helping them, moving booking, client and payment details between Karavex and the tools already in use.
Editorial system
Most studio stacks are held together by a person. Someone copies the shoot date into a planning tool, the client name into an accounting package, the payment status into a spreadsheet. It works, quietly, until the day it does not, and the tell is that nobody can say which copy is the current one.
Copy-and-paste is infrastructure nobody maintains.
Retyping is slow, but the bigger cost is that it is invisible. There is no record of which transfers happened, no signal when one is skipped, and no way to know that the planning tool is two bookings behind. Work that depends on somebody remembering to move information is fine on a quiet week and fails on a busy one, which is exactly when a missed handoff costs the most.
Let the event do the telling.
The durable version is to let the change announce itself. A webhook sends a booking or payment event to a URL you control, so the other system reacts when something actually happens instead of asking on a schedule. Two practical rules make it dependable: give each connection its own key with the least access it needs, so one can be revoked without breaking the rest, and verify the signature on every request before acting on it, because the endpoint is open to the whole internet.
A connection you cannot inspect is not an integration. It is a habit that happens to work.
Plan for the day the other end is down.
Integrations fail in undramatic ways: an endpoint returns errors for an afternoon, a certificate lapses, a deploy takes the receiver offline. The question is whether anyone finds out. Delivery history turns that into something visible, and rotating a key or an endpoint secret stays routine rather than an emergency. Start with one event that matters, watch it for a week, then add the next.
What to settle before the first connection goes live
- Which event the other system actually needs, and what it will do when it arrives.
- A key scoped to that connection alone, so revoking it breaks nothing else.
- Signature verification on the receiver, and someone who reads the delivery history.
Fewer copies, one source.
The aim is not to automate everything. It is that the booking record stays the version everything else follows, so the planning tool, the accounts and the calendar are reading from the same job rather than from three half-remembered copies of it.
Common questions
When is a webhook better than exporting a spreadsheet?
When the other system needs to act on a change rather than review it later. An export answers what happened last month. A webhook lets a tool react when a booking is confirmed or a payment lands, which is the difference between a report and a workflow.
How do I know a request really came from Karavex?
Verify the signature before acting on it. A webhook endpoint is a public URL, so anything on the internet can post to it. Checking the signature is what separates a real event from a request that simply looks like one.
What happens when the receiving system is down?
Check the delivery history rather than guessing. Failures are visible there, which is how an integration problem becomes something you can diagnose instead of a silence nobody notices until a client asks.