The economics of EUDI change when you sell software to businesses. Your company may only be one Adminyra customer, while the integration can enable dozens or hundreds of relying parties inside your product.
The SaaS application talks to one Adminyra API. Tenant context determines which relying party, application and verification policy applies to the request.
That removes the need to maintain a separate protocol implementation for every business using your software.
Centralised integration must not mean blended data. The control plane separates organisations, relying parties, applications, API credentials, verification metadata and usage.
The database foundation uses tenant-aware relationships and row-level security so a customer's configuration is not merely separated in the user interface.
Many vertical SaaS products serve sectors where individual businesses are too small to justify building their own digital identity infrastructure. A platform-level integration can make EUDI capabilities available to that entire market.
That is where Adminyra is positioning the product: not as another consumer wallet, but as reusable infrastructure behind existing software.
The architecture supports separate applications and credentials while still allowing the SaaS platform to operate the integration centrally. The exact credential model can be selected per partner.
Yes. Policies are modelled separately so one relying party can request a different set of attributes or use a different workflow from another.
That is the intended use. The public API and sandbox are being designed so existing SaaS products can integrate EUDI without becoming wallet infrastructure specialists.
Model the relying party, define the minimum data request and integrate the application flow before production trust infrastructure is required.