Provider Activation
Submit Activation
Submit activation data for one or more providers in a single call.
POST
Submits activation inputs for one or more providers on the app. Direct providers activate immediately, registration providers are queued for Hopae operator review, and contract providers return a
No ticket is written. The customer should email the contact to start the off-API onboarding flow.
contract_activation_required error directing the customer to the support contact. The response carries a per-provider result keyed by providerId — partial success is normal.
Request
Bearer <API_KEY> from Console > Developers > Workspace API Keys.application/jsonOptional. When provided, the request is idempotent across retries within the standard idempotency window.
Path parameters
Client identifier of the app.
Body
Map of The set of required fields for a registration provider is whatever
providerId to the field values for that provider. The value is a { fieldId: value } map; each value is a string or boolean. For direct providers, pass an empty object {}. For contract providers, the request body for that provider is ignored — the response is contract_activation_required (unless you set demo: true in sandbox).requirements returns from Get Providers with ?include=activation. Common field IDs include legalCompanyName, displayName, logo, registrationNumber, registeredAddress, vatNumber, serviceDescription, websiteUrl, contactEmail, contactPhone, privacyPolicyUrl, termsOfServiceUrl, and provider-specific fields (e.g., userDataLevel for SPID, bankName / useSsn / gdprArticle for BankID Norway, legalRepName for iDIN).When
true (default), common fields are mirrored into the app’s companyInfo so subsequent activations for the same app prefill them. Set to false to skip the companyInfo write — the activation ticket itself is still written.Sandbox only. Set to
true to skip operator review while testing: registration and contract providers auto-approve to activated about 1 second after submission, so you can exercise the full activated flow end-to-end. Omit it (or send false) to run the real review flow in sandbox. Sending true outside sandbox returns 400 VALIDATION_INVALID_PARAMETER. Combine with persist: false so test values are not written into the app’s shared companyInfo.Field validation
Field values are checked against the provider’s registration spec:- Missing required fields — fall back to the value cached in
companyInfo(if any). If still empty, the provider’s ticket is recorded withstatus: 'rejected'andrejection.reason: 'missing_required_fields'. Other providers in the same call are unaffected. - Empty strings, whitespace-only values, and
nullare treated as missing. - Field
type(text,email,url,checkbox,select) and option lists are advisory — server-side validation is currently scope-of-fields only. Provide well-formed values.
Response
200 OK with a JSON object keyed by providerId. Each value is one of three shapes:
Success / queued / rejected
status is the resulting ticket status — typically:
activatedfor direct providersactivation_requestedfor successful registration submissionsrejectedfor registration submissions that failed field validation (theactivation.rejectionblock on Get Providers carries the missing field IDs)
id is an act_... value. Sandbox otherwise behaves exactly like production — unless you submit with demo: true, which makes registration and contract providers return activation_processing and then auto-approve to activated about 1 second later.
Contract provider
Errors
These conditions abort the whole request — none of the requested providers are submitted.Concurrent submissions
The activation pointer on the app document is updated with optimistic concurrency. A losing writer is retried automatically once; if the second attempt also loses, the request fails with409 RESOURCE_CONFLICT. Submit the same provider again to retry — the previous submission’s data is overwritten unless the prior ticket was already activation_processing (which holds the slot until the operator finishes review).