Skip to content

Technical Support

What to do if things don’t work out?

The most important thing is to send a detailed description. This enables us to thoroughly examine the problem, resulting in a quicker solution.

We are happy to help!

Just one request - please allow us some time to process your support requests. Three business days is typical, but don't worry - we usually resolve issues on the same day.

Support Request Content

Support requests require a few, but essential pieces of information. The following list is a recommendation and can – depending on the issue - of course be extended or reduced. It is best to provide everything that you would expect yourself - at an expert level - to solve the problem.

Message Format

It is best to use simple, unformatted text!

This way we can reproduce the behavior, copy content for our own tests, ...
Please provide screenshots only if they are useful for better understanding (and if so, then please as PNG).

Timestamp

When exactly was the action performed? Time specifications should be in ISO 8601 format (e.g., 2022-01-13T13:40:52+01:00). Be sure to provide absolute information, i.e., date and time.

Relative indications such as last night, this morning, ... are not suitable.

Client / User

Which client_id and scopes were used? These, along with the client_secret, are required to generate the access token needed to access the API. For clarity, please provide only the client_id and scopes - do not include the client_secret or access_token.

✅ Send ❌ Do Not Send
client_id client_secret
scopes access_token

Public Client IP

From which public client IP was the action performed? In local networks, private IP addresses are usually assigned. Here, only the IP address that is used for routing to the internet is relevant. Private IP addresses (e.g., 10.x.x.x, 172.x.x.x, or 192.168.x.x) are not useful.

If multiple systems are in use (e.g., Load Balanced Cluster), check if the problem occurs on all systems. If the service works on some but not others, it is usually related to internal or external firewalls.

How to Find your Public IP

You may quickly look up your public IP address online.

Request

What request was sent? An HTTP Request consists of several components, including the URL, the method used (e.g., GET, POST, PUT, ...), as well as payload, parameters and headers. Please provide these details for better clarity.

Special software for API calls generally permit the export of the transmitted data in plain text or cURL format. If this is the case, then please include this export.

Tips for Including in Support Tickets
  • Be Clear and Complete: Include the full request, especially headers like Authorization or Content-Type, as they can be crucial for diagnosing issues.
  • Highlight Sensitive Information: If the request contains sensitive information (like API keys), consider redacting or highlighting them (e.g., Authorization: Bearer [REDACTED]).
  • Include Context: Provide additional context around the request, such as what you expected to happen, any error messages received, and relevant timestamps.
Example of Request

The exact request in HTTP form or the corresponding cURL call are best suited. It is important that the request itself was previously executed in the same way!

### request new OAID code
POST https://api.oaid.at/v2/pip/codes/
Accept: application/json
Content-Type: application/json
Authorization: Bearer <access_token>

{"tenant": "ofaa.demo", "version": "v8"}

Do Not Transmit Access Credentials

In the example, the authorization token (access_token) is specified. Even though it expires after some time, please do not transmit it.

Response / System Response

How did the service react, and what response was received? Did it result in a timeout, or did the service send a specific error message?

It is best to provide the exact HTTP response!

Example for Response 
https://api-demo.oaid.at/v2/pip/codes/

HTTP/1.1 401 Unauthorized
Date: Tue, 22 Mar 2022 11:12:06 GMT

{
"status_code": 401,
"message": "Unauthorized",
"detail": "Signature has expired.",
"hint": "Contact support"
}

Expectation / Expected Response

What result was expected, and what should have been returned?

If the server responded with 200 OK, but the response did not meet expectations, please specify which field(s) should have been different.

Intention

Please provide a non-technical description that specifies the purpose of the action from a business perspective, e.g.:

We want to pull the list of all our codes.

We need 50 new OAIDs.

Reproducibility

Is the behavior reproducible? To help us identify the issue, please clarify:

  • Does the unexpected behavior occur with one specific request or across multiple requests?
  • What sequence of API calls or specific actions led to the unexpected response?

Documentation

Have the request and response been compared to the documentation? Is there an incomprehensible discrepancy between the system's behavior and the documentation? Is the description correct but confusing?

If there is anything in this regard, please be sure to mention it. The documentation can be adapted in no time!

Template

The dropdown contains the above items as a text template. The template can be copied to the clipboard using the icon in the top right corner.

Description Template 
# Timestamp

# Client / User

# Public Client IP

# Request

# Response / System Response

# Expectation / Expected Response

# Intention

# Reproducibility

# Documentation

Where to Send the Description

Send the description to your designated OAID contact (e.g., OFAA). Only if you are our customer (yio), please submit it directly to us through our Support Ticket System.