Onboarding API

Edit on Github Send Feedback develop

Onboarding Server provides a RESTful API that allows to control specific parts of the onboarding process. Usage of the API is optional and depends on the system configuration.

Error Handling

Onboarding Server uses following format for error response body, accompanied by an appropriate HTTP status code. Besides the HTTP error codes that application server may return regardless of server application (such as 404 when resource is not found or 503 when server is down), following ERROR codes may be returned:

Error Code	HTTP Code	Description
ERROR_GENERIC	400	Issue with a request format or issue of the business logic
ERROR_UNAUTHORIZED	401	Unauthorized request

All error responses that are produced by the Onboarding Server have the following body:

{
  "status": "ERROR",
  "responseObject": {
    "code": "ERROR_GENERIC",
    "message": "An error message"
  }
}

API Endpoints

post /api/onboarding/client/evaluation Client Evaluation

If configured, the system waits for the event from an external system to continue with “client evaluation” phase. Use the endpoint bellow to proceed.

Request

Headers:
- Content-Type: application/json
- X-PowerAuth-Authorization: ...

{
  "processId": "String",
  "userId": "String",
  "identityVerificationId": "String",
  "evaluationResult": "String"
}

Request Params

Attribute	Type	Description
`processId`	`String`	ID of an onboarding process.
`userId`	`String`	ID of a user stored on onboarding process.
`identityVerificationId`	`String`	ID of the document verification subprocess.
`evaluationResult`	`String`	The evaluation outcome OK, NOK and WAIT. Process should either continue (OK), or fail/reset (NOK) or wait for asynchronous evaluation.

Response

{
  "result": "String",
  "resultReason": null
}

Attribute	Type	Description
`result`	`String`	The transition outcome OK, FAIL. Depends on the transition to the next phase was successful.
`resultReason`	`String`	The reason is used when result is FAIL to disclose the reason of failed process (for example user started new document verification subprocess).

post /api/onboarding/client/approval Onboarding Approval

If configured, the system waits for the event from an external system to continue with “onboarding approval” phase. Use the endpoint below to proceed.

Request

Headers:
- Content-Type: application/json
- X-PowerAuth-Authorization: ...

{
  "processId": "String",
  "userId": "String",
  "identityVerificationId": "String",
  "evaluationResult": "String"
}

Request Params

Attribute	Type	Description
`processId`	`String`	ID of an onboarding process.
`userId`	`String`	ID of a user stored on onboarding process.
`identityVerificationId`	`String`	ID of the document verification subprocess.
`evaluationResult`	`String`	The evaluation outcome OK, NOK and WAIT. Process should either continue (OK), or fail/reset (NOK) or wait for asynchronous evaluation.

Response

{
  "result": "String",
  "resultReason": null
}

Attribute	Type	Description
`result`	`String`	The transition outcome OK, FAIL. Depends on the transition to the next phase was successful.
`resultReason`	`String`	The reason is used when result is FAIL to disclose the reason of failed process (for example user started new document verification subprocess).

Last updated on Jun 09, 2025 (08:14) Edit on Github Send Feedback