Thanks! And yes, Multi-API systems are where security really becomes architectural as most of the hidden trust issues appear at the APIs boundary level.
Every API-to-API call carries assumptions about identity, data shape, privilege, and failure handling.
If even one of those assumptions is wrong, it becomes a vulnerability before any code is written.
That’s why Volume 1 leans heavily into trust boundaries and data-flow thinking.
What kind of API patterns do you work with most? Internal Services, third party calls or both?
I have failover code in place in case the various APIs are down, which happens sometimes! I’m calling them in functions because the app is still an MVP (no users yet!)
This sounds really useful! The stuff I build typically involves multiple APIs.
Thanks! And yes, Multi-API systems are where security really becomes architectural as most of the hidden trust issues appear at the APIs boundary level.
Every API-to-API call carries assumptions about identity, data shape, privilege, and failure handling.
If even one of those assumptions is wrong, it becomes a vulnerability before any code is written.
That’s why Volume 1 leans heavily into trust boundaries and data-flow thinking.
What kind of API patterns do you work with most? Internal Services, third party calls or both?
All third-party calls…various AI models plus email provider
Totally valid approach for an MVP. Direct calls + failover help you ship faster and keep things simple.
But once you have users or multiple features using those third-party APIs, a small internal gateway can give you:
- one place for retries/timeouts,
- consistent logging,
- and the ability to swap providers without touching core code.
- response validation
It’s a small investment that pays off big when the app starts scaling.
Will definitely look into it! Thank you! 🙏
That’s exactly where architecture-level security becomes critical.
With third-party AI models + email providers, the real risk lies in the assumptions about what those external APIs return, log, or forward onward.
In the book I talk about treating external APIs as untrusted boundaries by default:
• validate everything,
• enforce minimum privilege,
• never rely on their identity model blindly,
• and always assume their outages or changes will cascade into your system.
Out of curiosity, do you call these providers directly from core services, or do you front them with an internal gateway/adapter?
I have failover code in place in case the various APIs are down, which happens sometimes! I’m calling them in functions because the app is still an MVP (no users yet!)
Might consider some kind of gateway as it grows…