Unreleased documentation. These pages follow the main branch and can change before the next release. For supported guidance, use v0.44.0.
If you write a service or worker beside Registry Stack, including Base Registry Engine (BReg), preserve each product’s authority and use its released interface. Your module owns its own authorization, state, and recovery; an accepted review or a delivered notification does not grant it source mutation rights.
Authenticate to one resource
Section titled “Authenticate to one resource”Use the shared token profile and the token acquisition guide. Configure a separate token provider for each resource, audience, and scope set. The shared SDK authentication facade removes token acquisition plumbing while the selected product still checks its own principal, profile, and permissions.
The client API reference owns the supported language surfaces. Keep private keys server-side and request the scopes the deployment admits.
Handle problems, tracing, and uncertain effects
Section titled “Handle problems, tracing, and uncertain effects”The common HTTP problem contract owns the envelope and trace relationship. Branch on the owning product’s code and documented recovery action, and keep response trace context for diagnosis. Do not expose raw tokens or upstream transport errors to callers.
Use the product’s idempotency contract for the operation you call. Preserve the original key, body, profile, and revision guards after an uncertain write, then recover or read back its state. An operation that offers no idempotency key must not acquire a retry loop by convention. The shared client rules limit retries; the BReg API and Casework API define their operation-specific effects. Render’s correlation key is not a deduplication promise.
Receive signed delivery
Section titled “Receive signed delivery”Use the delivery signing contract for exact header and byte rules. Verify the original body bytes before parsing them, compare the signature in constant time, and bind deduplication to the verified delivery identity and payload. A completion wake announces that a result can be read; read that result from its authoritative product and correlate it to the request you accepted.
The deterministic cross-language fixtures come from that owning implementation. Run their exact bytes, key, and expected signatures through your language’s implementation, including the negative cases, before sending or accepting live traffic. The owning drift test ensures the fixtures and signing implementation agree.
Try the Python composition
Section titled “Try the Python composition”The Python reference service combines BReg, Casework, and Messaging over the released client interfaces, with a resource-bound token helper and a completion wake receiver. It is one example composition, not a required set of products. Its README owns installation, local configuration, and the runnable journey.
Describe the module optionally
Section titled “Describe the module optionally”Use existing Manifest data_services for a real service that serves declared datasets. A worker
can use the separate static modules description without a dataset. The
Manifest reference owns that
metadata contract. Manifest performs no health check, authentication, dynamic registration, or
capability enforcement for a described module.
Cookies on Registry Stack
We use optional cookies to understand how you use the main Registry Stack website and this documentation. If you contact us, we may link this activity to your enquiry. You can change your choice at any time. Read the privacy policy.
Your browser asks sites not to track you, so optional tracking stays off.
We could not use or save that choice. Optional tracking remains off.