From 851f60d6656da24322656673c45cde0d184916ea Mon Sep 17 00:00:00 2001 From: Max Martens Date: Tue, 14 Jul 2026 17:31:52 +0200 Subject: [PATCH] Updated SE-vouchers-supplier spec after review --- .../products/SE-vouchers-supplier.yaml | 98 +++++++++++++------ 1 file changed, 67 insertions(+), 31 deletions(-) diff --git a/src/openapi/products/SE-vouchers-supplier.yaml b/src/openapi/products/SE-vouchers-supplier.yaml index 1840357..1edc212 100644 --- a/src/openapi/products/SE-vouchers-supplier.yaml +++ b/src/openapi/products/SE-vouchers-supplier.yaml @@ -1,7 +1,7 @@ openapi: 3.0.1 info: title: Service Engine APIs for HTM voucher suppliers - description: Service Engine APIs for HTM voucher suppliers, this means all instances responsible for supplying vouchers. These are NOT the CRUD APIs to the data hub. These are ALSO NOT the api's for sales touchpoints. + description: Service Engine APIs for HTM voucher suppliers, this means all instances responsible for supplying vouchers. These are NOT the CRUD APIs to the data hub. These are ALSO NOT the APIs for sales touchpoints. version: "1.0" servers: - url: https://services.acc.api.htm.nl/abt/abtvouchers/1.0 @@ -24,15 +24,6 @@ paths: When a requiredProduct is configured, all attributes of the requiredProduct are also prerequisites for redeeming the voucher; thus they do not need to also be configured for the voucher definition. The requiredProduct itself is the single source of truth for this; and voucher definitions do not need to be updated if the requirements of the requiredProduct change. For example, if the requiredProduct requires an OVpay token, an OVpay token is automatically required to redeem issued vouchers. parameters: - - name: touchpointId - in: query - required: false - description: | - Filter the voucher definitions on a specific touchpointId. This means that only voucher definitions with active selling periods for the specified touchpoint are returned. - This query parameter is only intended for administrative purposes, since the touchpoint associated with the access token used in the request is used to determine which voucher definitions are returned. This query parameter can be used to retrieve voucher definitions for other touchpoints within the same retailer, for example to retrieve voucher definitions for a specific sales touchpoint that is different from the calling touchpoint. - schema: - type: integer - example: 12 - name: productId in: query required: false @@ -206,18 +197,15 @@ paths: /issuedvouchers: get: summary: Get a list of issued vouchers that were issued for a specific touch point - description: - Retrieve all issued vouchers for a specific touchpoint. This means that only vouchers that were issued by a touchpoint within the same retailer as the calling touchpoint are returned. + description: |- + Retrieve all issued vouchers that match the given query parameters. \ + At least on of the following query parameters should be provided: + - `issuedVoucherId` (internal and globally unique ID); + - `voucherCode` (code that the customer uses for redeeming the voucher, can be reissued as long as only one instance is active at the same time); + - `productId` (the productId of the voucher definition). + + When a voucher code has been issued multiple times, all issuedvouchers with the same voucher code will be returned, together with their statuses. parameters: - - name: touchpointId - in: query - required: false - description: |- - Filter the issued vouchers on a specific touchpointId. This means that only vouchers that were issued by the specified touchpoint are returned. - This query parameter is only intended for administrative purposes, since the touchpoint associated with the access token used in the request is used to determine which issued vouchers are returned. This query parameter can be used to retrieve issued vouchers for other touchpoints within the same retailer, for example to retrieve issued vouchers for a specific sales touchpoint that is different from the calling touchpoint. - schema: - type: integer - example: 12 - name: issuedVoucherId in: query required: false @@ -416,6 +404,22 @@ paths: } ] } + "400": + description: Bad request + content: + application/problem+json: + schema: + $ref: "#/components/schemas/rfc9457" + examples: + Missing required query parameters: + summary: Missing required query parameters + value: + { + "type": "https://example.com/probs/bad-request", + "title": "Missing required query parameters", + "detail": "At least one of the following query parameters should be provided: issuedVoucherId, voucherCode, or productId.", + "instance": "/issuedvouchers" + } "403": description: Forbidden content: @@ -466,10 +470,20 @@ paths: } post: summary: Issue a voucher for a specific voucher definition - description: | - Issue a voucher for a specific voucher definition. Vouchers can only be issued on a one-by-one basis, so that it is always clear what voucher code has been issued for specific voucher claims (which by itself my not uniquely identify the voucher; however the voucher code is guaranteed to be unique). The voucher can only be issued if the calling touchpoint (recognized by the access token) has an active selling period for the voucher definition (recognized by the productId).\ - The \"fromInclusive\" and \"untilInclusive\" fields specify the date-time range in which the voucher can be redeemed by the customer. This has nothing to do with the allowed start date of a requiredProduct (for this, the existing order flow logic is applied).\ - If the voucher definition contains mandatoryCustomerDataItems, a value (to be checked against customer input when redeeming the voucher) has to be provided for each of these items. + description: |- + Issue a voucher for a specific voucher definition. Vouchers can only be issued on a one-by-one basis, so that it is always clear what voucher code has been issued for specific voucher claims (which by itself may not uniquely identify the voucher; however the voucher code is guaranteed to be unique).\ + The voucher can only be issued if the calling touchpoint (recognized by the access token) has an active selling period for the voucher definition (recognized by the productId). + + When providing a voucher code, the supplier is allowed to re-use a voucher code that has already been issued, but only if the previously issued voucher is not active anymore.\ + This means that a voucher code can only be re-used once the previous instance has a `voucherStatus` of "revoked" or "expired".\ + Redeemed is NOT a valid end-state, as this voucher might still refer to an active travel product (which can be revoked by revoking the voucher). + + The `fromInclusive` and `untilInclusive` fields specify the date-time range in which the voucher can be redeemed by the customer.\ + This has nothing to do with the allowed start date of a requiredProduct (for this, the existing order flow logic is applied). + + If the voucher definition contains mandatoryCustomerDataItems, a value (to be checked against customer input when redeeming the voucher) has to be provided for each of these items. + + A newly issued voucher will always receive the status "new". Vouchers can only be redeemed after they have been explicitly set to the status "issued" (via `PATCH /issuedvouchers/{issuedVoucherId}`), for example when the customer receives the actual voucher code. tags: - Vouchers requestBody: @@ -481,7 +495,9 @@ paths: examples: Issue a voucher and supply own voucher code: summary: Issue a voucher and supply own voucher code - description: This allows the voucher supplier to supply its own voucher code, which can be useful if the supplier already has its own (internal or external) source for voucher codes. The supplied voucher code must be unique - if this code is already in use, the request will fail. + description: |- + This allows the voucher supplier to supply its own voucher code, which can be useful if the supplier already has its own (internal or external) source for voucher codes.\ + The supplied voucher code must be unique (or a previous instance must be revoked/expired, see main endpoint description). value: { "voucherCode": "HTM-A7J-128-PYT", @@ -498,12 +514,21 @@ paths: } Issue a voucher and receive a voucher code (generated by ABT backend) in response: summary: Issue a voucher and receive a voucher code (generated by ABT backend) in response - description: If the supplier is not able to generate its own unique voucher codes, it can issue a voucher without supplying any voucher code - the ABT backend will then receive a unique voucher code and return it in response. + description: |- + If the supplier is not able to generate its own unique voucher codes, it can issue a voucher without supplying any voucher code.\ + The ABT backend will then generate a unique voucher code and return it in response. value: { "fromInclusive": "2026-01-01T00:00:00.000+00:00", "untilInclusive": "2030-12-31T23:59:59.000+00:00", - "productId": 264 + "productId": 264, + "voucherClaims": + [ + { + "mandatoryCustomerDataItemId": 8, + "value": "1980-06-31", + } + ], } responses: "201": @@ -521,7 +546,7 @@ paths: "voucherCode": "HTM-A7J-128-PYT", "fromInclusive": "2024-10-04T00:00:00.000", "untilInclusive": "2024-11-04T00:00:00.000", - "voucherStatus": { "voucherStatusId": 2, "name": "issued" }, + "voucherStatus": { "voucherStatusId": 1, "name": "new" }, "product": { "productId": 263, @@ -573,12 +598,12 @@ paths: $ref: "#/components/schemas/rfc9457" examples: Voucher code already in use: - summary: Voucher code already in use + summary: Another active voucher instance already exists for this voucher code value: { "type": "https://example.com/probs/bad-request", "title": "Invalid voucher code", - "detail": "This voucher code is already in use.", + "detail": "Another active voucher instance already exists for this voucher code.", "instance": "/issuedvouchers" } Missing mandatory voucher claims: @@ -614,6 +639,9 @@ paths: summary: Update the status of an issued voucher description: |- Update the status of an issued voucher. Not every state change is allowed; an error will be returned if an invalid state change is attempted.\ + If a redeemed voucher is revoked using this endpoint, it may also impact any active travel products that have been acquired using this voucher.\ + This depends on specific business rules that are agreed upon with HTM. + Possible voucher statuses are: - 1 = new - 2 = issued @@ -630,8 +658,16 @@ paths: schema: $ref: "#/components/schemas/supplierTouchpointUpdateIssuedVoucherRequest" examples: + Mark a voucher as issued: + summary: Mark a voucher as issued + description: Mark a voucher as issued. Only vouchers with a status of "issued" can actually be redeemed. + value: + { + "voucherStatusId": 2 + } Mark a voucher as revoked: summary: Mark a voucher as revoked + description: Mark a voucher as revoked. This may also impact any active travel products that have been acquired using this voucher. This depends on specific business rules that are agreed upon with HTM. value: { "voucherStatusId": 4