Skip to main content

Outcome

You have one Partner-managed company UUID, the exact UUID of every inline membership, a Partner lifecycle webhook whose one-time secret is already in a restricted secret sink, and the company’s current readiness projection.

Lifecycle context

Creation commits the company aggregate, inline memberships, provisional authorization, events, and idempotent response together. Provisional access is not confirmed consent: the invited admin later confirms the current authorization version. Readiness is independent. A draft Case may be created while readiness is false, but finalization re-checks readiness atomically. Every inline user receives an invitation. The fresh 201 response returns each new inline membership’s setup_url once; reads and an idempotent replay omit it. The link leads to password setup only for an account this request created. Every account that existed before receives a sign-in link instead. An invitee who lost a password-setup link and never used the account can set a first password through Passwort vergessen in the paywise portal; the reset link goes only to their own address. See Manage memberships. Use the sandbox host (https://api-sandbox.paywise.de) and a Partner key. Give each logical write a stable named key. An ambiguous timeout is recovered only by replaying the same body and key within a bounded attempt budget.

1. Prove the sandbox before creating the webhook

Every Partner write in this workflow is immediately preceded by this authenticated information request. Require the case-insensitive X-Paywise-Environment response header to equal sandbox.

2. Create the lifecycle subscription and capture its secret once

The response reveals secret_key exactly once. Store it directly in a restricted secret manager or mode-0600 file; never print it or retain it in ordinary logs.

3. Prove the sandbox again before company creation

4. Create the company aggregate

The inline admin is part of the same atomic command. Capture the returned company and membership id fields directly; never search a list by name, email, customer number, or first-row position.

5. Reconcile the exact company URL

Runnable onboarding workflow

This complete workflow bounds ambiguous-response recovery, proves the sandbox before every write attempt, captures all returned UUIDs, and writes the one-time webhook secret without logging it.
Python workflow

Representative response

Failure and recovery

  • Replay an ambiguous webhook or company create only with its original key and byte-equivalent body. Bound the attempts; never generate a duplicate command.
  • A validation error starts a new logical command only after correcting the rejected fields. 409 idempotency_key_expired is terminal for that key.
  • Render every readiness issue. Keep draft creation available, but require current readiness and current access immediately before finalization.
  • The fresh company-create response returns each newly issued setup_url once; reads and an idempotent replay omit it. Setup mail is also delivered to the invitee. Do not infer whether an inline email created or reused a global user.