Build with the boundaries in view.
A useful integration begins with identity, ownership and a clear distinction between network access and service permission.
Native admission
The documented protocol is yura-native/1. Its participants are an account-authenticated client, a durable device identity, an admission service and the WireGuard transport.
Account session → device registration challenge → Ed25519 proof of key possession → account-owned device credential → admission challenge bound to transport key → authorized, expiring Native session → heartbeat or revocation
Signature and replay boundaries
Registration and admission use domain-separated transcripts. The client signs the exact canonical transcript using its installation identity. Single-use challenges and expiry constrain replay. Never substitute a WireGuard key for the Ed25519 identity key.
Private service ownership
The account-owned service interface registers, lists, updates and deletes the owner’s private targets. Legacy publisher-token routes remain a separate compatibility path. A service registration routes traffic; the application must still enforce its own access policy.
Static creation contract
Studio staging separates editable drafts from immutable published artifacts. It validates relative file paths and asset limits; project operations are account-scoped and writes require session authorization and CSRF protection. Preview origins, deployment locking and managed runtime isolation are separate production concerns.
Integrating responsibly
Keep credentials out of URLs and logs. Preserve certificate verification. Treat admission failures, expiry and revocation as normal lifecycle events. Use the documented current contract for a client implementation; do not infer production Studio endpoints from this marketing demonstration.