The decision
APIs are the right tool for data exchange between systems that have agreed to integrate.
butlerzz is the right tool when you need a standard protocol, consumer representation, and structured consent — at network scale, without bilateral agreements.
Direct APIs
RTL+ ↔ Telekom (custom integration)
RTL+ ↔ Bank (custom integration)
RTL+ ↔ Household ✗ impossible — no API
= N × M integrations, N × M maintenance
butlerzz (IBP)
RTL+ implements IBP once
← reaches every household on the network
← reaches every company on the network
= 1 integration → N + M connections
The real differentiators
Any API can be made legally binding — DocuSign, PSD2, Adobe Sign all use APIs with Qualified Electronic Signatures on top. Legal weight is not the distinction. These are:
01
Standardisation
Every company builds their own API. butlerzz is one standard — implement IBP once and communicate with every other butler on the network, with no bilateral agreements.
02
Consumer accessibility
Companies can build APIs. Households cannot. butlerzz gives every household a butler that represents them — without a developer, a contract or an IT team.
03
Consent architecture
APIs transfer data. butlerzz mandates explicitly encode who authorised the action, what exactly is permitted, for how long, and what is not permitted. Structured, auditable, revocable.
04
Discovery & network
How does your butler find RTL+'s butler? butlerzz.com is the directory. N × M bilateral API integrations vs 1 integration that reaches every party on the network.
Company butlers also communicate with each other (via opzz). Two scenarios:
Neither has an API
Law firm ↔ Accounting firm
Landlord ↔ Repair shop
Doctor ↔ Insurance company
butlerzz is the only option. Most of the economy lives here.
Both have APIs
Insurance company ↔ Bank
RTL+ ↔ Payment processor
Employer ↔ Employee (via opzz ↔ itemzz)
APIs for data exchange internally. butlerzz for mandate-carrying interactions between them.
The right analogy
Banks all have internal APIs. But for inter-bank communication they use SWIFT — a shared protocol — not because they couldn't build bilateral APIs, but because:
The mandate triggers an API action inside each company. But the inter-company layer is IBP — not a custom bilateral API that has to be negotiated, built and maintained for every new relationship.
APIs inside their systems — ERP, CRM, billing, inventory, data sync.
butlerzz between their butlers — mandates, consent, authority, cross-border interactions.
The two are complementary. butlerzz is the missing layer that APIs were never designed to provide: consent, authority and mandate exchange between principals and their agents — at network scale, with legal weight, across the EU.
Join the network
Ready to connect your butler?
Join the waitlist →IBP v1.0 · GDPR-native · EU hosting · eIDAS 2.0 ready