Coverage validation

Default validation for coverages

In most cases, PolicyCenter restricts the following behaviors:

• Coverages
  • Cannot create an unavailable coverage
  • Cannot delete a required coverage
• Coverage terms
  • Cannot set the value for an unavailable coverage term
  • Cannot set the value for a read-only coverage term
  • Cannot set the value for a hidden coverage term
  • Cannot set the value to an unavailable option or package
  • Cannot set the value to an unavailable typekey
  • Cannot set the value outside of the min/max range

Some of these behaviors may be the result of the submission becoming out of sync. In these cases, you can rectify the situation by calling the appropriate /sync-coverages endpoint. For more information, see Synchronization and deferred validation.

Deferring validation

For Cloud API, the default validation behavior is referred to as immediate validation. In this approach, validation is provided with each call. A validation error in one call can prevent later calls from executing. This approach is appropriate for caller application the build submissions interactively, such as those backing a user interface.

There is a second behavior called deferred validation. In this approach, validation takes place only once the caller application has put the submission into what it believes to be a consistent state. This is an option for non-interactive caller applications with sufficient authorization. This approach can simplify submission processing by preventing validation checks when the submission is known to potentially be in an inconsistent state. This approach can also reduce the need to determine if coverages need to be synchronized.

For more information on deferred validation, see Synchronization and deferred validation.