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.

You receive periodic emails detailing updates and changes to our cloud software product to fulfill our legal obligation of keeping you informed about any modifications or enhancements to the service. These communications are purely transactional and do not contain any form of advertising.

Please be aware that you cannot unsubscribe from these transactional emails as receiving updates is mandatory under our legal terms.

If you wish to stop receiving these transactional emails, the only way to do so is to terminate your subscription. You can manage your subscription by logging in here. After logging in, navigate to the customer area located in the top-right corner and select the appropriate subscription to cancel.

If you are unable to access your subscription details or require assistance, please contact our support team here.

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.

If your company requires manual approval of outgoing connections for security reasons, you can add the following DNS names to your firewall:

• PTV Developer API Usage: api.myptv.com
• PTV Developer Documentation: developer.myptv.com
• PTV Developer Code Samples: developer-applications.myptv.com
• PTV Logistics Account: myptv.com / login.myptv.com / account.myptv.com / gateway.myptv.com / legal.myptv.com / curie-static.myptv.com
• PTV Logistics Helpdesk Portal: support.ptvlogistics.com

Note that the IPs these DNS names resolve might change at any time and can differ depending on the geographical region. Specific functionality can require allowing additional third party services (e.g. initial sign up in the browser requires reCAPTCHA (google.com) to be accessible).

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.

Some user data is temporary and will automatically deleted after some time. It is guaranteed that the following data is available at least the given time:

• Result of asynchronous requests can be retrieved at least for 24 hours after the calculation has finished.
• Route IDs are valid for at least 12 hours.

The following user data is persisted until explicitly deleted by the user:

• Custom Road Attribute Scenarios

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].

The term "maintenance" refers to a service or feature that has reached its end-of-life stage.

• The feature will no longer receive new functionalities or general enhancements.
• Major bugs and critical CVEs will still be addressed.
• The service or feature will remain available for a defined period. Customers will be notified at least 12 months in advance before it is discontinued.
• The service or feature is marked in the documentation with the label [MAINTENANCE].

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