Onboarding

Workflows > Onboarding

Purpose: Onboarding your integration on Go client(s)

This workflow is highly recommended to use if your integration are meant for public use by many clients, or if you have a private integration that will be used on many clients.

The onboarding workflow is a process that is initiated in your end (your system), allowing a user to login to Go and accept onboarding and activation of your integration for the relevant client(s) the user have access to. The end result of the onboarding is that your integration is activated on the client(s), and the clientkey(s) returned to you in a secure manner abstracted from the user. Meanwhile, the user is redirected to an url of your choosing.

Endpoint

Description of core flow

  1. Starting from application with an user interface and user input, your system initiate the onboarding with the api call

  2. Temporary url is returned, requiring user login to Go

  3. The user is presented with either:
    a. A specific client the integration request access to
    b. A list of clients to choose from, where the integration will gain access.

  4. The user accepts, and is returned to the redirect url you provided. In the header, a token is provided.

  5. You use the token in the final api call, to retreive the clientkey(s) for the onboarded client(s).

  6. After safely managing and storing the clientkey(s), you are ready to communicate with the client(s) using the api. If any other practical setup or necessary steps are needed, we encourage you to include them in a step by step dialogue as part of the onboarding process.

Prerequisites

  • The redirect url used in the intial POST operation must be whitelisted by the api team before used. This applies for the demo environment and the production environment (separate whitelisting's). You are not supposed to operate with several redirect url's or create whitelisted url's that are client specific for each client onboarding. Only one url is needed - you can use parameters in the url if you need variants in your end.

  • Whitelisting - what we validate in the whitelist check:

    • Https (TLS encryption)

    • Path match the whitelistet url path

    • Domain and subdomain match the whitelisted url domain and subdomain

    • Any parameters beyond this is ignored and can be included by you as you see fit

  • The Go user that perform the onboarding need access to do so (in Go) for the clients in question. If the initiate onboarding is sent with a client organization number, lack of access will result in an error message for the user. If initita onboarding is sent without a client organization number, the user will be presented a list of clients - but only the clients the user have acccess to onboard.

Related workflows

  • General relevance for all integrations intended to be activated on many clients.

Dictionary/Terminology