Skip to main content
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 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

​
string
required
Bearer <API_KEY> from Console > Developers > Workspace API Keys.
​
string
application/json
​
string
Optional. When provided, the request is idempotent across retries within the standard idempotency window.

​
Path parameters

​
string
required
Client identifier of the app.

​
Body

​
object
required
Map of 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).
The set of required fields for a registration provider is whatever 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).
​
boolean
default:"true"
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.
​
boolean
default:"false"
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 with status: 'rejected' and rejection.reason: 'missing_required_fields'. Other providers in the same call are unaffected.
  • Empty strings, whitespace-only values, and null are 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:
  • activated for direct providers
  • activation_requested for successful registration submissions
  • rejected for registration submissions that failed field validation (the activation.rejection block on Get Providers carries the missing field IDs)
In sandbox, tickets are real, so 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

No ticket is written. The customer should email the contact to start the off-API onboarding flow.

​
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 with 409 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).