How the Business Process and Blueprints relate to one another.
Business Processes are flexible and can be entirely unique from one instance to the next. This can add a lot of challenges in providing users and integrations with something predictable. This is where Blueprints come into play, a Blueprint is a named template for Business Process where the name is used as a mounting point for common behaviors like Triggers and webhooks.
TLDR: Blueprints are the class, and Business Processes are the instances.
Triggers
So presuming you've figured out what to Blueprint you likely now need to glue other systems to it, to either create a Business Process (Trigger) or recieve information from a Business Process within it (webhook subscription). A Blueprint is quite flexible in what it can be fed, either directly or from a Trigger because of the dynamic variables that can be defined within it.
Webhooks
Webhook subscriptions are also flexible as you can define multiple per Blueprint with conditions on when they should apply. So multiple downstream systems can be configured against the same Blueprint.
Blueprint Webhooks
There are webhook Subscription paths that can be access relative to a Blueprint, which will be documented shortly (8-8-2024)
Possibilities
Multiple Sources
Its possible to have multiple external sources sending data into the same Trigger, or via different Triggers, with the same Blueprint. So you could have Stripe Invoice webhooks and Zoho Invoice webhooks invoking the same Blueprint.
Business Process Chaining
A Business Process can be invoked with the resolved or failed state of another Business Process (from a specific Blueprint). Or, you can have a webhook defined on a Blueprints Business Processes actions (with a condition on the Action type) invoke the https:POST Trigger of another Blueprint. Either of these can give you a pretty powerful logical flow of the sucess or fail of an entire process, or just the Action within a Business Process.