Skip to content

Request-Confirm Workflow

A valid access token is required for all processes. This can be obtained via the access credentials; the necessary steps are outlined here. With a valid access token, you can begin the creation of an OAID. If multiple OAIDs are needed, pull codes repeatedly within the token’s validity period, using the same access token.

Request - Create OAID

Pulling a code creates a new OAID in the register and returns it in the response. This OAID is linked to the user's account and cannot be changed. From a technical aspect, it is a POST request that instructs the API to add a new OAID to the user’s list. Once an OAID is pulled, it can no longer be reverted.

$ curl --request POST --location "https://api.oaid.at/v1/pip/codes/" \
$  --header "Authorization: Bearer <access_token>" \
$  --header "Accept: application/json" \
$  --header "Content-Type: application/json" \
$  --data '{"tenant": "fiberpark", "version":"v8", "external_id": "7710fb1e-0efb-42af-9e30-ed46188d9bb9"}'
---> 100%

{
    "tenant": "fiberpark",
    "code": "AB1C23E4",
    "token": "requested",
    "version": "v8",
    "status": "active",
    "external_id": "7710fb1e-0efb-42af-9e30-ed46188d9bb9",
    "created_at": "2022-03-01T10:35:03.392+01:00",
    "modified_at": "2022-03-01T10:35:03.392+01:00",
    "_links": {
        "self": "https://api.oaid.at/v1/pip/codes/AB1C23E4/"
    }
}

Tip

We recommend using the external_id attribute, which associates the OAID with an internal user system key. By filtering on external_id, the interaction with the API can be made more robust.

Warning

An account can manage several clients. The specification of the tenant is therefore mandatory. The value must match the assigned clients.

Confirm - Confirm OAID

The OAID generated in the previous step has not been confirmed yet. Complete the activation process by confirming it, which provides proof of receipt. Only then will the OAID be activated for further use.

Confirmation is done by setting the so-called Milestone Token to confirmed. Since this is a specific command, this action is implemented as a separate PUT method on the token attribute of the respective OAID in the API.

$ curl --request PUT --location "https://api.oaid.at/v1/pip/codes/AB1C23E4/token/"  \
$  --header "Authorization: Bearer <access_token>" \
$  --header "Accept: application/json" \
$  --header "Content-Type: application/json" \
$  --data '{"token": "confirmed"}'
---> 100%
{
    "token": "confirmed"
}

Tip

The chronological proximity of the actions as depicted in the process diagram is not necessary. REQUEST and CONFIRM can be performed in different sessions and with a longer time interval between them.