Frequently Asked Questions

You need to sign up for a PTV account and then activate your free subscription of PTV Developer. If you already have a PTV account, you can directly activate your free product. No payment details are needed to activate your free product.

No. Every account can only activate one free subscription of PTV Developer but multiple paid subscriptions.

You can use the avatar menu on the top right corner to reach the Manage Profile section and update your personal information.

In the Manage Profile section you have the possibility to delete your account. Please note that you can only delete your account if no subscription is active.

Within your product instance you can create, rename and delete API keys in the API Keys App.

For the free subscription one API key is included. If you need more API keys, please contact us and we will find a solution that fits best to your needs.

The API keys are needed to authenticate against PTV Developer APIs. Check the Quick Start of the API documentations for more details on the authentication options.

If you want to run performance or load tests, please contact us and we will find a solution that fits best to your needs.

Learn how to generate clients for PTV Developer APIs in this tutorial. Alternatively you can download clients for Java, C# and TypeScript from GitHub.

The version number consists of three fields, namely major.minor.bugfix, e.g. 1.2.3. The exact version number can be found in the API Changes of each PTV Developer API, the first two fields can also be found in the API specification.

All PTV Developer APIs will be backward compatible as long as the major version does not change (e.g. 1.x.x). 

Changing the minor version (e.g. 1.2.x) denotes compatible API extensions so that there will be a benefit from updating the clients. 

Changing the bugfix version (e.g. 1.2.3) denotes fixes which do not affect the API such as functional bugfixes, documentation etc.

Clients should follow some rules which are common practice in the communication with APIs to guarantee compatibility. We handle the following changes as being compatible:

• New operations.
• New optional properties in requests. There will never be new required properties in requests.
• New optional and required properties in responses, the client should be robust against these changes and be tolerant with unknown fields. Response properties marked as required give the client a hint that this property will always be present so that checks for existence can be omitted.
• New values in enumerations used only in requests.
• New values in enumerations used in responses if being sent only when explicitly requested by a new property introduced in the same version.
• New values in string properties flagged as 'x-extensible-enum', the client should implement a fallback mechanism for unknown values.
• Relaxing constraints of properties such as increasing array lengths, extending value ranges or removing string patterns.

Compatibility is guaranteed only for the messages sent and received (sometimes referred to as 'on the wire'). Any code generated from the API specification is not covered. The semantics of the properties will be stable, but the contents of properties may change as algorithms evolve, results will improve and data will be updated regularly.

Properties may be marked as deprecated. That means that they will still be supported but their use is discouraged. See the documentation for information on which property to use instead.

The term "experimental" denotes a service or feature that is still in the early phases of development. It could still be going through extensive testing and not be completely stable.

• API stability: An experimental feature or service's API may be unstable. This implies that depending on the input or the direction of the work, it could alter regularly or, in certain cases, it might be entirely removed.
• Completeness: A feature or service that is still being tested may not be fully functioning. It offers a sneak preview of something that is still in the development stage.
• Documentation: It is labelled with the tagline [EXPERIMENTAL].

The term "preview" refers to a service or feature that is more developed than an experimental one. Although the core functions are established and reliable, it could still be missing some features that are planned for the full release.

• API Stability: A preview feature or service's API is stable, indicating users may anticipate predictable behavior and replies.
• Completeness: A feature or service is more comprehensive than an experimental one. The majority of the functions are available, however certain intended features could be absent at this time; these features will be introduced in the future.
• Documentation: It is labelled with the tagline [PREVIEW].

If the endpoint requires a parameter in the path and this parameter is missing you will get a http response code 404 (Not Found) even if the rest of the url is correct. You have to add the required parameter to the url in order to get a successful response or an error message with more details if something else is wrong with the parameter.

The free subscription is only for testing and integration purposes. If you want to roll out your application for commercial use, you need to contact us and we will find a solution that fits best to your needs.

You can find the terms of use for different regions by using the according link below.

EU - English
EU - German
US - English