--- title: "POST /echo" method: POST path: "/echo" tags: ["monitoring"] --- # POST /echo `POST /echo` ## Request - Base URL: `https://financial-services.developer.worldline.com` (the document declares no server; this is the origin it was published from) - URL: `https://financial-services.developer.worldline.com/echo` - Auth: none declared - TypeScript: (a function with typed inputs; its response is checked against the schema) Test the availability of the web service. Timestamps are exchanged between the client and the server. ## Request body - EchoMessage: Echo message. - `header` Header, required: Metadata of the message. - `service` string, required: Service code of the caller, defined during project. - `issuerCode` string, required: Unique identifier code of issuer. - `subIssuerCode` string, required: Unique identifier code of sub-issuer. - `requestId` string, uuid, required: Unique identifier of the request. - `keyTag` string: Key indicator shared between client and server. - `iv` string: IV value used to crypt data. Can either be the requestId without dashes, a random value, or equals to the null IV. 32 characters long in case of CBC mode, 24 characters long in case of GCM mode (expect if configured otherwise). - `body` EchoBody, required: Body of echo message, which contains the timestamp of the message. - `timestamp` string, yyyyMMddHHmmss, required: Timestamp of the message. - `signature` string: The signature of the message. The signature is optional and is only filled and/or checked if explicitly required. Otherwise, signature value is ignored in responses and left empty in requests. Signatures can be activated for each issuer, sub-issuer individually and at a method level. To pass validation, the signature format must be RFC 7515 (JSON Web Signature) and RFC 7797 (Unencoded or detached payload) compliant. As such, a typical signature should look like this: `[header]..[signature]`, where: - `[header]` is the Base64 URL encoded value of the JOSE header which contains the key ID, algorithm and object type. For example: `eyJraWQiOiJzaWduIiwidHlwIjoiSk9TRStKU09OIiwiYWxnIjoiUlMyNTYifQ`, which gives, in clear JSON: `{"kid":"sign","typ":"JOSE+JSON","alg":"RS256"}`. The `kid` (Key ID) and `alg` header fields are both required to perform the check. An additional `jku` parameter (JWKS URL where to retrieve the public key) can also be specified. Otherwise, it should be expected for public keys to have been exchanged beforehand. The `typ` is only there by convention and should only be set to `JOSE` or `JOSE+JSON` since were are not dealing JWT (tokens) here. - `[signature]` is the Base64 URL encoded value representation of the signature output. The payload used to generate the signature consists of the JSON serialization of the whole object, excluding old signatures and null values, which is then Base 64 URL encoded as well. If the signature from the response contains a payload value, then it will be ignored in favor of the actual object. Currently supported algorithms are: - RS256 - RS384 - RS512 - ES256 - ES256K - ES384 - ES512 ## Response `200` Echo response. - EchoMessage: Echo message. - `header` Header, required: Metadata of the message. - `service` string, required: Service code of the caller, defined during project. - `issuerCode` string, required: Unique identifier code of issuer. - `subIssuerCode` string, required: Unique identifier code of sub-issuer. - `requestId` string, uuid, required: Unique identifier of the request. - `keyTag` string: Key indicator shared between client and server. - `iv` string: IV value used to crypt data. Can either be the requestId without dashes, a random value, or equals to the null IV. 32 characters long in case of CBC mode, 24 characters long in case of GCM mode (expect if configured otherwise). - `body` EchoBody, required: Body of echo message, which contains the timestamp of the message. - `timestamp` string, yyyyMMddHHmmss, required: Timestamp of the message. - `signature` string: The signature of the message. The signature is optional and is only filled and/or checked if explicitly required. Otherwise, signature value is ignored in responses and left empty in requests. Signatures can be activated for each issuer, sub-issuer individually and at a method level. To pass validation, the signature format must be RFC 7515 (JSON Web Signature) and RFC 7797 (Unencoded or detached payload) compliant. As such, a typical signature should look like this: `[header]..[signature]`, where: - `[header]` is the Base64 URL encoded value of the JOSE header which contains the key ID, algorithm and object type. For example: `eyJraWQiOiJzaWduIiwidHlwIjoiSk9TRStKU09OIiwiYWxnIjoiUlMyNTYifQ`, which gives, in clear JSON: `{"kid":"sign","typ":"JOSE+JSON","alg":"RS256"}`. The `kid` (Key ID) and `alg` header fields are both required to perform the check. An additional `jku` parameter (JWKS URL where to retrieve the public key) can also be specified. Otherwise, it should be expected for public keys to have been exchanged beforehand. The `typ` is only there by convention and should only be set to `JOSE` or `JOSE+JSON` since were are not dealing JWT (tokens) here. - `[signature]` is the Base64 URL encoded value representation of the signature output. The payload used to generate the signature consists of the JSON serialization of the whole object, excluding old signatures and null values, which is then Base 64 URL encoded as well. If the signature from the response contains a payload value, then it will be ignored in favor of the actual object. Currently supported algorithms are: - RS256 - RS384 - RS512 - ES256 - ES256K - ES384 - ES512 --- [API](https://skmtc.dev/worldline/apis/authentication-ws-client.md) - [All operations](https://skmtc.dev/worldline/apis/authentication-ws-client/llms.txt) - [OpenAPI document](https://skmtc.dev/worldline/apis/authentication-ws-client/revisions/5c21f3ad0e19?raw)