OpenActive Developers
Data ValidatorDataset DashboardW3C Community Group
  • Welcome to our community
  • Publishing Data
    • Data Feeds
      • How an RPDE data feed works
      • Types of RDPE feed
      • Implementing RPDE
      • Testing RPDE feeds
      • Scaling RPDE feeds
    • Activity list references
    • Including geo coordinates
    • Schedules
    • Dataset Sites
    • Virtual Events
    • On-Demand Events
    • Opening Hours
    • Data Quality
  • Using data
    • Harvesting opportunity data
      • Large Integers in JavaScript
    • Tutorial: Consuming an RPDE feed
    • Attribution
  • Open Booking API
    • Key Decisions
    • Implementing booking
    • Testing booking
      • Configuring Test Suite
      • Implementing the Test Interface
        • Test Interface Actions
        • Create Opportunity Endpoint
      • Random Mode: Generating Test Opportunity Data
      • Running Test Suite
      • Generating the Conformance Certificate
  • Data Model
    • Data Model Overview
    • @context and JSON-LD
    • Types Reference
      • Action
      • AudioObject
      • BabyChanging
      • Barcode
      • BookingService
      • BooleanFormFieldSpecification
      • Brand
      • ChangingFacilities
      • ConceptScheme
      • Concept
      • CourseInstance
      • Course
      • Creche
      • CustomerAccount
      • DataCatalog
      • DataDownload
      • Dataset
      • DropdownFormFieldSpecification
      • DynamicPayment
      • Entitlement
      • EventSeries
      • Event
      • FacilityUse
      • FileUploadFormFieldSpecification
      • GeoCoordinates
      • HeadlineEvent
      • ImageObject
      • IndividualFacilityUse
      • InternalApplicationError
      • InternalLibraryConfigurationError
      • InternalLibraryError
      • Lease
      • LocationFeatureSpecification
      • Lockers
      • MediaObject
      • OfferOverride
      • Offer
      • OnDemandEvent
      • OpenBookingError
      • OpeningHoursSpecification
      • OrderItem
      • OrderProposal
      • OrderQuote
      • Order
      • Organization
      • ParagraphFormFieldSpecification
      • Parking
      • PartialSchedule
      • Payment
      • Person
      • Place
      • PostalAddress
      • PriceSpecification
      • PrivacyPolicy
      • PropertyValueSpecification
      • PropertyValue
      • QuantitativeValue
      • Schedule
      • ScheduledSession
      • SessionSeries
      • ShortAnswerFormFieldSpecification
      • Showers
      • Slot
      • SportsActivityLocation
      • TaxChargeSpecification
      • TermsOfUse
      • Terms
      • Toilets
      • Towels
      • VideoObject
      • VirtualLocation
      • WebAPI
  • Specifications
    • Specifications Overview
  • Useful links
    • Data Visualiser
    • Data Validator
    • Dataset Dashboard
    • Non-technical Guidance
  • OpenActive on GitHub
    • Overview
    • Activity List
    • Community
    • Controlled Vocabularies
    • Dataset Publication
    • Documentation
    • Implementation Support
    • Programmes
    • RPDE
    • SKOS
    • Specifications
    • Validators
Powered by GitBook
On this page
  • OpenActive Conformance Certificates
  • Example certificate
  • Obtaining a certificate
  • Publishing your certificate
  • Certificate self-validation
  • Certificate external validation
  • Certificate composition
Edit on GitHub
  1. Open Booking API
  2. Testing booking

Generating the Conformance Certificate

PreviousRunning Test SuiteNextData Model Overview

Last updated 1 year ago

OpenActive Conformance Certificates

An OpenActive Conformance Certificate offers a mechanism by which implementing systems can prove their conformance to the OpenActive specifications.

Example certificate

An example conformance certificate can be found here:

Note that this example is frequently generated for the OpenActive .NET Reference Implementation as part of the CI of the OpenActive Test Suite itself.

Obtaining a certificate

The OpenActive Test Suite can be configured to output a Conformance Certificate upon all tests passing.

This is best achieved as part of a continuous integration script that runs these tests of your UAT environment (or test environment, if you do not have a UAT environment).

A Conformance Certificate is issued to cover a subset of the features of the specifications that are implemented - which are , and hence only guarantees a complete implementation of that subset.

Certificates are designed to be published frequently, to demonstrate continued conformance, especially as the test suite is improved to test for additional edge cases within the features selected.

To obtain a certificate, simply update your config/dev.json with the following:

  "integrationTests": {
    "generateConformanceCertificate": true,
    "conformanceCertificateId": "https://acmebooker.example.com/openactive/certificate",
    // ...

The certificate ID is the URL where the certificate will be hosted (see below section), which must match in order for the certificate to be valid.

Publishing your certificate

This certificate must be hosted somewhere publicly accessible, ideally under the same or subdomain as your dataset site.

Static file hosting such as GitHub pages or an Amazon S3 bucket are both recommended.

Your UAT continuous integration script should upload a fresh certificate upon each successful run of the OpenActive Test Suite.

Upload scripts can be created for e.g. Amazon S3 and GitHub pages.

The certificate should be linked from your dataset site, to make it easily accessible to integrators in both human and machine-readable forms.

Certificate self-validation

A valid certificate will look as follows:

An invalid certificate will display an error message as follows:

Certificate external validation

External validation is available for integrating services interested in establishing the validity of a certificate.

Simply send a request as follows:

https://conformance-certificate-validator.openactive.io/validate?url={url}&holder={holder}

The parameters accepted are:

  • url - The URL of the conformance certificate

  • holder - The certified booking services name, which should be taken from bookingService.name (or otherwise publisher.name) within the dataset site - which ensures the certificate is only referenced from relevant system.

Certificate composition

The certificate is composed of three key elements:

  • A human readable HTML page

  • An embedded machine-readable JSON-LD snippet

All three of these components must be coherent and match in order for the certificate to be valid.

The test suite results included as evidence are redacted to remove all domain names from URLs, to ensure the security of your UAT infrastructure.

The evidence zip file can be extracted from the HTML page using the "Download Evidence" button when opening the page in a browser.

Note that the certificate is named index.html by default to allow it to be referenced at a path such as

When the certificate is opened in a browser, it sends its contents to , which runs checks to ensure its integrity and that its test coverage matches that of the latest test suite for the features selected.

An embedded zip file of evidence of the test suite results that were used to obtain this certificate, as is .

https://acmebooker.example.com/openactive/certificate
https://conformance-certificate-validator.openactive.io/
common practice
https://certificates.reference-implementation.openactive.io/examples/all-features/random/
configured in the test suite
Valid Certificate Screenshot
Invalid Certificate Screenshot