Skip to content

List Cash Registers

fiskaly Logo
API docs by Redocly

fiskaly SIGN AT (1.2.5)

Download OpenAPI specification:

fiskaly GmbH: info@fiskaly.com URL: https://fiskaly.com

Imprint: fiskaly.com/impressum | Privacy Policy: fiskaly.com/datenschutz

Introduction

The fiskaly SIGN AT is a RESTful API. The fiskaly SIGN AT is compliant with the Austrian RKSV (Registrierkassensicherheitsverordnung).

The fiskaly SIGN AT is a platform-independent and software-only solution. The only thing you need to integrate the fiskaly SIGN AT is a stable Internet connection.

The fiskaly SIGN AT:

  • has resource-oriented URLs,
  • accepts JSON-encoded request bodies,
  • returns JSON-encoded responses,
  • uses standard HTTP status codes and verbs,
  • is easy to integrate with your system.

Versioning

The fiskaly SIGN AT follows Semantic Versioning.

The version number has a pattern of MAJOR.MINOR.PATCH. We increment the

  • MAJOR version when we make incompatible API changes,
  • MINOR version when we add functionality in a backwards-compatible manner, and
  • PATCH version when we make backwards-compatible bug fixes.

The current MAJOR version 1 is reflected in the API's base URL: https://rksv.fiskaly.com/api/v1.

Idempotent Requests

The fiskaly SIGN AT is idempotent. Idempotence means you can send the same request several times safely. The result will be the same as if you have sent it only once.

For example, if you request to sign a Receipt but don't receive a response, you can send the request again with the same request body. The receipt is guaranteed to be signed only once.

UUIDv4

This API uses UUIDv4. Requests like Create a Cash Register and Create a Signature Creation Unit create new resources. To run such requests, generate a random UUIDv4. Then pass the UUIDv4 in the request body. This UUIDv4 will be assigned to the newly created resource.

A good way to generate a UUIDv4 is to use a library in your programming language of choice (like this) or an online generator (like this). A UUIDv4 created this way will be random and unique throughout the system.

Request IDs

The fiskaly SIGN AT associates a unique identifier with each request. You will find this request identifier in the response headers, under request-id. If you need help with a request you have issued, please provide the request identifier. We will find your request and help you faster.

Metadata

Most resources in the API (e.g. Cash Registers) have a metadata property. You can store any additional information in the metadata.

For example, in the metadata of a Receipt you can store an ID of a receipt or invoice from your system.

You can specify up to 20 key-value pairs in the metadata object. A key can be up to 40 characters long. A value can be up to 500 characters long.

Meta Properties

Each response contains the following meta properties:

  • _id is the ID of the resource.
  • _type is the type of the resource (e.g. RECEIPT).
  • _env is either LIVE or TEST.
  • _version is the API version.

Changes

MINOR and PATCH changes

v1.2.5

Changes added

v1.2.4

Changes added

  • Error with code B13 from FON is now being handled. This error means that the resource being patched is already in the desired status. e.g. the transition/synchronisation of a cash register to a state in which it is already in FON.

    • When reporting ending of OUTAGE for a Cash Register, if this error happens the API will try to synchronize the Cash Register state to INITIALIZED
    • Any other scenario will throw an error with code E_FON_REQUEST_FAILED as it previously did, with a more specific message instead

  • Please take into account that desynchronizations between resources in our end and FON should be fixed automatically by the changes provided in v.1.2.2

v1.2.3

Breaking changes

  • (POST) /api/v1/auth endpoint has been refactored:
    • From now on, refresh_token value will be validated accordingly to JSON Web Token (JWT) standards before being sent to the authorization service. If validation fails, API will respond with a 401 Unauthorized error with a descriptive error with code E_AUTHENTICATION_ERROR instead of the previous E_CLIENT_ERROR

Changed added

  • (POST) /api/v1/auth:
    • From now on, if refresh_token value is expired or invalid in the authorization service's side, API will respond with a 401 Unauthorized error with a descriptive error message from the authorization service. The error code provided will be E_CLIENT_ERROR.

v1.2.2

  • The response from patching SignatureCreationUnits (SCU) in the endpoint updateSignatureCreationUnit and Cash Registers in the endpoint updateCashRegister has been changed.
    • From now on, all state changes that involve an interaction within FinanzOnline (FON) may return a new 504 Gateway Timeout response instead of the usual 408 Request Timeout
    • This 504 Gateway Timeout response is triggered when the request against FON fails due to a timeout error on their side. In this case, the request may or may not be processed by FON
    • For more information about the HTTP 504 Gateway Timeout code, please refer to this page

Features added

  • To address the FON timeout issue explained above, a new synchronization flow has been developed to synchronize SCUs and cash registers.

    • Once a FON timeout is detected, a background process to synchronize the resource is started

    • This process follows these steps:

      • Fetches the resource against FON
      • Compares the state of the resource in the FON service and in the fiskaly system
      • When an inconsistency is detected, the resource is automatically patched in the fiskaly system to ensure that the state of the resource is the same as it is in FON

    • The state of the resources can then be retrieved via the endpoints retrieveSignatureCreationUnit for SCUs and retrieveCashRegister for cash registers

v1.2.1

  • Bug fixing: negative offset and limit query parameters now throw a 400 Bad Request validation error to the client

v1.2.0

  • Added Organization Configuration resource. In this version this Configuration will be responsible of enabling/disabling monthly and yearly receipt validations. By default these options are enabled, just as how it previously worked
  • Added Update Configuration route in order to update current Organization's configuration
  • Added Retrieve Configuration route in order to retrieve current Organization's configuration

v1.1.1

  • the version 3.0.3 of OpenAPI is used now instead of 3.1.0
  • the incorrect usage of the allOf property in the OpenAPI specification is replaced with inline schema definitions
  • the 404 errors are now referenced by NotFoundErrorResponse in the OpenAPI schema

v1.1.0

  • Added Validate receipt route in order to validate a single Cash Register's Receipt

v1.0.3

  • OpenAPI specification now uses the Environment schema consistently instead of the Env schema
  • The TurnoverCounter property is now accessible on the CashRegisterResponse

v1.0.2

  • The Export a Cash Register route now has a more specific response schema.
  • Schema for errors has been added and endpoints have been extended by possible error status codes.
  • Introduced schemas for request / response objects in various endpoints and referenced them from there.
  • Unused schemas were removed.

v1.0.1

  • Made schema compliant to the FON Web Service specification
    • the minimum length of fon_user_pin is now 5 characters
    • the fon_participant_id should now be between 8 and 12 characters long and adhere to the defined pattern
    • the fon_user_id should now be between 5 and 12 characters long

v1.0.0

  • Feature-complete and stable API specification.

v0.0.1-draft

  • First draft version.

Processes

Overall Flow

Set up Resources

Before you can fiscalize receipts, a few steps have to be performed.

Create Organizations

Make sure that each taxpayer (= your customers) has set up at least one managed organization through the Management API. Then you can create a Signature Creation Unit and all the needed Cash Registers for the managed organization.

Before You Create Resources

Each Signature Creation Unit and Cash Register has to be reported to the fiscal authorities through FinanzOnline. During the initialization of a Cash Register, a zero-valued receipt is created. This receipt is then validated through FinanzOnline. This is done to make sure that the financial authorities can verify the signatures created during the fiscalization process.

The interactions with the fiscal authorities happen automatically when the states of the Signature Creation Unit and Cash Register resources change. All you need to do is create the resources through our API and perform the state transitions in the correct order.

We need you to collect and provide a set of credentials from your customers. Your customers can generate those credentials through FinanzOnline as the users of RKSV (= "Registrierkassen Web-Service Benutzer"). You can provide the credentials to us through the Authenticate FON endpoint. If the credentials are correct, the endpoint will return with the 200 status code and the authentication_status of AUTHENTICATED. We will then securely store the credentials.

Creating The Resources

After the interactions with FinanzOnline are done, you will have to create a Signature Creation Unit. To do that, use the Create Signature Creation Unit Operation. A Signature Creation Unit is responsible for signing receipts.

SCU Flow

When your Signature Creation Unit is set up, you can create Cash Registers. They represent physical cash registers and are responsible for managing the DEP7 and recording of receipts. The recording of the receipts includes the creation of machine readable codes, signing, and cryptographic chaining. The Cash Registers have to be reported to FinanzOnline. You should only create as many Cash Registers as there are in a given store. Otherwise, problems could arise during an audit.

Cash Register Flow

Daily Operations

Fiscalizing receipts

After the setup has been completed, the daily operations start. The key operation for that is the Sign Receipt Operation. It is used to fiscalize a receipt and retrieve the QR Code Data. The QR Code Data has to be printed on the receipt given to a customer.

Receipt Flow

Decommissioning Cash Registers

A Cash Register needs to be decommissioned in two cases:

  • Planned decommissioning: A cash register has reached its planned end of life. Transition the Cash Register to state DECOMMISSIONED.
  • Decommissioning due to non-repairable defect. Transition the Cash Register to state DEFECTIVE.

Both state transitions will trigger a report to the financial authorities through FinanzOnline.

Decommissioning Signature Creation Units

A Signature Creation Unit needs to be decommissioned in two cases:

  • You no longer want to use the fiskaly system. Transition the Signature Creation Unit to state DECOMMISSIONED.
  • Decommissioning due to non-repairable defect. Transition the Signature Creation Unit to state DEFECTIVE.

Both state transitions will trigger a report to the financial authorities through FinanzOnline.

Outage & Failure Handling

We handle the outage of SCUs ourselves. This involves detecting outages, reporting them to FinanzOnline, and creating the neccessary zero-valued receipts. The zero-valued receipts signal to the fiscal authorities that the outage is over.

We cannot monitor the state of Cash Registers. Handling outages of the Cash Registers is a shared responsibility of the API integrator and the taxpayer (= operator of ERS / PoS). If a Cash Register is temporarily not usable, it has to be transitioned into the state OUTAGE. It has to be done at most 48 hours after the defect was detected. This gets reported to FinanzOnline. When the cash register is usable again, transition it back into INITIALIZED. This reports a fault clearance to the fiscal authorities.

Special Cases During Signing Receipts

The RKSV has two subsystems:

  • Security System ("Sicherheitseinrichtung")
  • Signature Creation Unit ("Siegelerstellungseinheit")

The Signature Creation Unit provides the signatures.

The Security System includes the Signature Creation Unit and has additional functions. It manages the DEP, creates the machine readable codes signed by the SCU, and performs cryptographic chaining.

We handle an outage of the Signature Creation Unit ourselves. We detect outages, report them (including state changes for the affected API resource) and try to bring the SCU into normal operations again. If an outage has occured, the hints field of the receipt will contain Sicherheitseinrichtung ausgefallen (German from "SCU unavailable").

If the Security System is unavailable, you have to queue the receipts on your end. They will be signed once SIGN AT is available again.

Audit (DEP7)

An auditor can ask you to provide an export of all your fiscalization activities. This export is called DEP7 (pursuant to paragraph 7 of the RKSV). To retrieve this export run the Export a Cash Register endpoint with the relevant cash_register_id.

The auditor can also request an export for a specific time period or a range of receipt numbers. You can retrieve an export adjusted to the required parameters. To do this, set filters as query parameters in the Export a Cash Register request.

DEP7 Flow

Offboarding

As part of the offboarding process, there are a few essential actions we would kindly ask you to undertake. These actions are intended to align with FinanzOnline and to prevent billing for unused fiskaly SIGN AT products.

  1. The first step is to set all the cash registers from the state INITIALIZED to the state DECOMMISSIONED.
    To do this, you need to use the updateCashRegister endpoint and specify in the request body that the state should be set to DECOMMISSIONED.
    When a cash register is decommissioned, a decommissioning receipt is created on our side and validated by FinanzOnline. We also report to FinanzOnline the DECOMMISSIONED state of the cash register.
    Please note that a cash register can only be DECOMMISSIONED from the INITIALIZED or OUTAGE state.

  2. The second step is to set the Signature Creation Unit in state INITIALIZED to the DECOMMISSIONED state.
    To do this, you need to use the updateSignatureCreationUnit endpoint and specify in the request body that the state should be set to DECOMMISSIONED.
    We report to FinanzOnline the DECOMMISSIONED state of the Signature Creation Unit.

Offboarding

Resources

Cash Register

The Cash Register resource is a representation of a physical cash register.

This resource manages the lifecycle of a cash register in RKSV and fiscalizes the receipts.

It reports the changes in its lifecycle states to FinanzOnline.

To start fiscalizing receipts with a Cash Register, you have to go through the following steps.

  1. Create a Cash Register with the Create Cash Register Operation. The Cash Register gets assigned the state CREATED.
  2. Run Update Cash Register Operation with the state field of the payload set to REGISTERED. It reports the new Cash Register to FinanzOnline. The state of the Cash Register is now REGISTERED.
  3. Run the Update Cash Register Operation with a state of INITIALIZED. It fiscalizes and validates the initial receipt with FinanzOnline. The Cash Register moves into the state INITIALIZED. Now it can fiscalize receipts.

The third step requires at least one Signature Creation Unit (SCU) to be in the state INITIALIZED.

Signature Creation Unit (SCU)

A Signature Creation Unit provides the signatures, which are required to fiscalize the receipts. During fiscalization, every receipt is brought into a special format and gets signed using the SCU.

Before a Signature Creation Unit can provide signatures, two steps have to be performed:

  • Certificate & Key Pair creation: This is done internally by creating the resource on our side (= CREATED).
  • FinanzOnline registration: Every SCU has to be registered with FinanzOnline. This can be done by running Update Signature Creation Unit Operation with the state field of the payload set to INITIALIZED.

FinanzOnline (FON)

FinanzOnline is a web application of the Austrian Ministry of Finance. Our API interacts with FinanzOnline during the fiscalization process. FinanzOnline provides a service called "Registrierkassenwebservice" (cash register web service). Your customers (= the taxpayers) have to create a user with this service and give you their credentials. Then you have to perform the Authenticate FON Operation with these credentials.

This operation usually only has to be performed once.

This operation has to be redone when:

  • the taxpayer deletes their FON web service user. In that case, another user has to be created and you will have to authenticate with the new credentials.

Receipt

The Receipt resource represents a fiscalized receipt within the RKSV. It includes the machine-readable code and the schema you provided when fiscalizing the receipt. The machine-readable code gets printed on the physical receipt. Some receipts (e.g. a yearly receipt) also include the result of the FinanzOnline validation.

Validation and reporting of such receipts will be performed automatically by fiskaly SIGN AT whenever required (e.g. at the beginning of a new year).

Errors and Status Codes

The fiskaly SIGN AT uses standard HTTP status codes to indicate the success or failure of requests:

Status 2xx

Status codes in the 200-299 range indicate success.

Status 4xx

Status codes in the 400-499 range indicate errors that have been caused by the requesting application (e.g., a malformed request body has been sent).
Retrying such requests with the same request body is pointless and will result in the same status code again. Some 4xx errors can be handled programmatically. The error response is in JSON format and is structured like this:

{
"status_code": 400,
"error": "Bad Request",
"code": "E_SOME_ERROR",
"message": "Something bad happened"
}

The response will contain an error code or other information that reveals the reason of the error. Change the request accordingly before retrying. Below you can find the most frequent errors and how to fix them.

How to handle 4xx errors

400 Bad Request
  • E_FAILED_SCHEMA_VALIDATION

    Your request doesn't comply with the defined schema. Fix you request body and parameters according to the error message and run the endpoint again.

  • E_SCU_ALREADY_EXISTS

    There already exists an SCU with the scu_id you passed with the request. Run the Retrieve SCU endpoint with the scu_id you tried to use. If you tried to make an idempotent request, make sure that the SCU has the same legal_entity_name and legal_entity_id as you passed in the oridinal request payload and its state is either PENDING or CREATED.

  • E_SCU_LIMIT_REACHED

    You are only allowed to have one active SCU. An active SCU is an SCU in the states of INITIALIZED or OUTAGE. Run the List SCUs endpoint. Check how many SCUs are active. If you want to replace an SCU, run the Update SCU endpoint for this SCU with the state property of the payload set to DECOMMISSIONED. Then create a new SCU with the Create SCU endpoint.

  • E_INVALID_VAT_ID

    The VatId you tried to use as the legal_entity_id has an incorrect format. Follow the instructions in the error message and retry the request with a valid VatId.

  • E_INVALID_AUSTRIAN_TAX_ID,

    The TaxId you tried to use as the legal_entity_id has an incorrect format. Follow the instructions in the error message and retry the request with a valid TaxId.

  • E_INVALID_GLN

    The Gln you tried to use as the legal_entity_id has an incorrect format. Follow the instructions in the error message and retry the request with a valid Gln.

  • E_INVALID_LEGAL_ENTITY_ID

    The legal_entity_id you provided has an incorrect format. Follow the instructions in the error message and retry the request with a valid legal_entity_id.

  • E_ILLEGAL_SCU_STATE_TRANSITION

    The SCU state transition you are trying to make is not allowed. The error message explains why this state transition is invalid. The SCU part of the Resources section describes the correct lifecycle of an SCU.

  • E_CASH_REGISTER_ALREADY_EXISTS

    There already exists a Cash Register with the cash_register_id you passed. This error is returned if the state of the Cash Register with this cash_register_id is not CREATED. Run the Retrieve a Cash Register endpoint with the cash_register_id and check the state of the returned Cash Register.

  • E_ILLEGAL_CASH_REGISTER_STATE_TRANSITION

    The Cash Register state transition you are trying to make is not allowed. The error message explains why this state transition is invalid. The Cash Register part of the Resources section describes the correct lifecycle of a Cash Register.

  • E_INITIAL_RECEIPT_MISSING

    You tried to sign receipts with a Cash Register that is not in a state of INITIALIZED. Run the Retrieve a Cash Register endpoint with the cash_register_id of the Cash Register you are using. Check that the state field of the Cash Register is INITIALIZED. If it is in the state CREATED follow the instructions for the Initialize Cash Register endpoint to initialize it.

  • E_FILTER_LIMIT_EXCEEDED

    The limit for the number of Cash Registers to fetch you set is too high. Set a limit below 100 and retry the request.

401 Unauthorized
  • E_MISSING_FON_CREDENTIALS

    You need to authenticate the taxpayer with FON with before using this endpoint. Run the Authenticate FON with the taxpayer credentials and retry the request.

  • E_FON_AUTH_FAILED

    The FON authentication request failed. The error message contains the response and reason for failure returned by FON. Fix the FON authentication request payload according to the response and retry the request.

  • E_AUTHENTICATION

    The JWT token authentication failed for your request. The error message explains what went wrong. Run the Authenticate API enpoint to get a new token and retry your original request.

404 Not Found
  • E_SCU_NOT_FOUND

    No SCU with the scu_id you provided was found. Run the Retrieve SCU endpoint with the scu_id you used to see if this SCU exists.

  • E_NO_INITIALIZED_SCU

    You need to have an SCU in the state INITIALIZED to use this endpoint. Run the List SCU request to see which SCUs you have. Then use the Update SCU endpoint to initialize one of your SCUs.

  • E_RECEIPT_NOT_FOUND

    No Receipt was found for the receipt_id_or_number you provided. Run the Retrieve a Receipt request with the receipt_id_or_number you used to see if such a Receipt exists.

  • E_CASH_REGISTER_NOT_FOUND

    No Cash Register with the cash_register_id you provided was found. Run the Retrieve a Cash Register endpoint with the cash_register_id you used to see if this Cash Register exists.

408 Request Timeout
  • E_FON_REQUEST_TIMEOUT The FON request timed out. Run your request again.

Status 5xx

Status codes in the 500-599 range indicate errors on the server side. These errors are temporary. You can safely retry (see Idempotent Requests) the same request after a delay. We recommend an exponential backoff for your retry logic. Otherwise you might run into a 429 (Too Many Requests) error.

Known issues

Quick Start

For a quick first demo, you may use Postman. We prepared a Postman collection that allows you to step through the most important functions of this API.

  1. Download the Postman application.

  2. Create an API key and secret via the fiskaly dashboard: api key and secret

  3. Insert your API key and secret to get your personalized Postman environment:

  1. Download the Postman collection.

  2. Start Postman and select Upload Files from the Import dialog:

    File > Import (Ctrl+O)

    postman upload files

  3. Select the collection and environment files that you downloaded:

    postman select files

  4. The Postman screen should now look like this:

    postman screen

  5. Select the SIGN AT environment:

    postman select environment

  6. Run the demo:

    postman run demo

FAQ

The FAQs have been migrated to a new location: support.fiskaly.com

Authentication

Authenticate API

To access our API, you need to have a valid JWT token. This endpoint creates the token with your api_key and api_secret. If you don't have an api_key, you can create one via the fiskaly dashboard. The api_secret will be generated for you after you create the api_key. The token must be sent with every following request in the Authorization header field using the Bearer authentication scheme. See details here.

Request Body schema: application/json
One of
api_key
required
string (ApiKeyKey) non-empty

Key of the API Key and Secret.

api_secret
required
string (ApiKeySecret) non-empty

Secret of the API Key and Secret.

Responses

Request samples

Content type
application/json
Example
{
  • "api_key": "string",
  • "api_secret": "string"
}

Response samples

Content type
application/json
{
  • "access_token": "string",
  • "access_token_claims": {
    },
  • "access_token_expires_in": 0,
  • "access_token_expires_at": 1577833200,
  • "refresh_token": "string",
  • "refresh_token_expires_in": 0,
  • "refresh_token_expires_at": 1577833200
}

Authenticate FON

The fiscalization process requires interactions with FinanzOnline (FON). This includes registering Cash Registers and Signature Creation Units, validating Receipts, etc. The fiskaly SIGN AT automates all those steps.

Our system communicates with FinanzOnline (FON) in the name of the taxpayer. The taxpayer must create a FinanzOnline Cash Register web service user ("Registrierkassen-Webservice-Benutzer", pages 60-63). Then you must use those credentials to authenticate the taxpayer with FON through this endpoint.

Note: The credentials of this Cash Register Web Service User must be provided only once for authenticating with FON. The Cash Register web service user remains authenticated with FON indefinitely.

Note: You must authenticate with FON before transitioning Signature Creation Units and Cash Registers to INITIALIZED.

Note: For requests requiring our system to communicate with FinanzOnline (FON), any downtime or unavailability of the FinanzOnline (FON) service may impact such requests.

Authorizations:
JWT
Request Body schema: application/json
fon_participant_id
required
string (FonParticipantId) [ 8 .. 12 ] characters [0-9A-Za-z]{8,12}

The "Teilnehmer-Identifikation" part of the FinanzOnline Cash Register Web Service User ("Registrierkassen-Webservice-Benutzer") credential triplet to be provided by the taxpayer.

fon_user_id
required
string (FonUserId) [ 5 .. 12 ] characters

The "Benutzer-Identifikation" part of the FinanzOnline Cash Register Web Service User ("Registrierkassen-Webservice-Benutzer") credential triplet to be provided by the taxpayer.

fon_user_pin
required
string (FonUserPin) [ 5 .. 128 ] characters

The "PIN" part of the FinanzOnline Cash Register Web Service User ("Registrierkassen-Webservice-Benutzer") credential triplet to be provided by the taxpayer.

Responses

Request samples

Content type
application/json
{
  • "fon_participant_id": "stringst",
  • "fon_user_id": "string",
  • "fon_user_pin": "string"
}

Response samples

Content type
application/json
{
  • "fon_participant_id": "stringst",
  • "fon_user_id": "string",
  • "authentication_status": "AUTHENTICATED",
  • "time_authentication": 1577833200
}

Signature Creation Units

Create a Signature Creation Unit

This endpoint creates a Signature Creation Unit. The Signature Creation Unit is identified by a signature_creation_unit_id. The signature_creation_unit_id must comply with the UUIDv4 standard and should be generated on your side.

When you create a Signature Creation Unit, its state is usually set to CREATED.

In some rare cases it may happen that the Signature Creation Unit can not be created immediately. This will be reflected by a transient PENDING state that will eventually change to CREATED at a later point in time. Simply retry the request or use the Retrieve a Signature Creation Unit endpoint to regularly check the state of the Signature Creation Unit.

Use the Update a Signature Creation Unit endpoint to transition a Signature Creation Unit to the state INITIALIZED in order to be able to use it for signing Receipts.

Authorizations:
JWT
path Parameters
signature_creation_unit_id
required
string <uuid> (SignatureCreationUnitId) [a-f0-9]{8}-?[a-f0-9]{4}-?4[a-f0-9]{3}-?[89ab...
Example: 1c81cb86-c2e8-4074-afc3-a0601b2bf063

Identifies a Signature Creation Unit.

Request Body schema: application/json
object (MetadataRequest) <= 20 properties

You can use this parameter to attach custom key-value data to an object. Metadata is useful for storing additional, structured information on an object.

Note: You can specify up to 20 keys, with key names up to 40 characters long and values up to 500 characters long.

required
VatId (object) or TaxId (object) or Gln (object) (LegalEntityId)

A unique identifier of the legal entity that operates the Signature Creation Unit.

legal_entity_name
string (LegalEntityName)

The name of the legal entity that is bound to the Signature Creation Unit.

Responses

Request samples

Content type
application/json
{}

Response samples

Content type
application/json
{
  • "_id": "1c81cb86-c2e8-4074-afc3-a0601b2bf063",
  • "_type": "SIGNATURE_CREATION_UNIT",
  • "_env": "TEST",
  • "_version": "1.2.5",
  • "state": "CREATED",
  • "legal_entity_id": {
    },
  • "legal_entity_name": "string",
  • "certificate_serial_number": "5c8e5",
  • "time_pending": 1577833200,
  • "time_creation": 1577833200,
  • "metadata": {}
}

Retrieve a Signature Creation Unit

This endpoint returns information about a specific Signature Creation Unit.

Authorizations:
JWT
path Parameters
signature_creation_unit_id
required
string <uuid> (SignatureCreationUnitId) [a-f0-9]{8}-?[a-f0-9]{4}-?4[a-f0-9]{3}-?[89ab...
Example: 1c81cb86-c2e8-4074-afc3-a0601b2bf063

Identifies a Signature Creation Unit.

Responses

Response samples

Content type
application/json
{
  • "_id": "1c81cb86-c2e8-4074-afc3-a0601b2bf063",
  • "_type": "SIGNATURE_CREATION_UNIT",
  • "_env": "TEST",
  • "_version": "1.2.5",
  • "state": "PENDING",
  • "legal_entity_id": {
    },
  • "legal_entity_name": "string",
  • "certificate_serial_number": "5c8e5",
  • "time_pending": 1577833200,
  • "time_creation": 1577833200,
  • "metadata": {},
  • "time_initialization": 1577833200,
  • "time_decommission": 1577833200,
  • "time_outage": 1577833200,
  • "time_defect": 1577833200
}

Update a Signature Creation Unit

This endpoint updates a Signature Creation Unit.

In order to be able to use a Signature Creation Unit for signing Receipts it needs to be transitioned to the state INITIALIZED.

Once a Signature Creation Unit has eventually reached its end-of-life this has to be reflected by setting its state to DECOMMISSIONED.

Authorizations:
JWT
path Parameters
signature_creation_unit_id
required
string <uuid> (SignatureCreationUnitId) [a-f0-9]{8}-?[a-f0-9]{4}-?4[a-f0-9]{3}-?[89ab...
Example: 1c81cb86-c2e8-4074-afc3-a0601b2bf063

Identifies a Signature Creation Unit.

Request Body schema: application/json
state
required
string
Enum: "INITIALIZED" "DECOMMISSIONED"

Responses

Request samples

Content type
application/json
{
  • "state": "INITIALIZED"
}

Response samples

Content type
application/json
{
  • "_id": "1c81cb86-c2e8-4074-afc3-a0601b2bf063",
  • "_type": "SIGNATURE_CREATION_UNIT",
  • "_env": "TEST",
  • "_version": "1.2.5",
  • "state": "PENDING",
  • "legal_entity_id": {
    },
  • "legal_entity_name": "string",
  • "certificate_serial_number": "5c8e5",
  • "time_pending": 1577833200,
  • "time_creation": 1577833200,
  • "metadata": {},
  • "time_initialization": 1577833200,
  • "time_decommission": 1577833200,
  • "time_outage": 1577833200,
  • "time_defect": 1577833200
}

List all Signature Creation Units

This endpoint lists all available Signature Creation Units.

Authorizations:
JWT
query Parameters
order
string
Default: "ASC"
Enum: "ASC" "DESC"

Determines the sorting order.

limit
integer [ 1 .. 100 ]
Default: 100

Limits the number of returned results.

offset
integer >= 0
Default: 0

Skips the specified number of results from the result set.

Responses

Response samples

Content type
application/json
{
  • "data": [
    ],
  • "count": 9007199254740991,
  • "_type": "SIGNATURE_CREATION_UNIT_LIST",
  • "_env": "TEST",
  • "_version": "1.2.5"
}

Retrieve metadata of a Signature Creation Unit

This endpoint retrieves additional structured information about a Signature Creation Unit.

Authorizations:
JWT
path Parameters
signature_creation_unit_id
required
string <uuid> (SignatureCreationUnitId) [a-f0-9]{8}-?[a-f0-9]{4}-?4[a-f0-9]{3}-?[89ab...
Example: 1c81cb86-c2e8-4074-afc3-a0601b2bf063

Identifies a Signature Creation Unit.

Responses

Response samples

Content type
application/json
{}

Update metadata of a Signature Creation Unit

This endpoint creates or updates additional structured information about a Signature Creation Unit.

Authorizations:
JWT
path Parameters
signature_creation_unit_id
required
string <uuid> (SignatureCreationUnitId) [a-f0-9]{8}-?[a-f0-9]{4}-?4[a-f0-9]{3}-?[89ab...
Example: 1c81cb86-c2e8-4074-afc3-a0601b2bf063

Identifies a Signature Creation Unit.

Request Body schema: application/json
<= 20 properties
property name*
additional property
string <= 500 characters

Responses

Request samples

Content type
application/json
{}

Response samples

Content type
application/json
{}

Cash Registers

Create a Cash Register

This endpoint creates a Cash Register. The Cash Register is identified by a cash_register_id. The cash_register_id must comply with the UUIDv4 standard and should be generated on your side.

When you create a Cash Register, its state is set to CREATED.

Use the Update a Cash Register endpoint to transition a Cash Register to the state INITIALIZED in order to be able to use it for signing Receipts.

Authorizations:
JWT
path Parameters
cash_register_id
required
string <uuid> (CashRegisterId) [a-f0-9]{8}-?[a-f0-9]{4}-?4[a-f0-9]{3}-?[89ab...
Example: 1c81cb86-c2e8-4074-afc3-a0601b2bf063

Identifies a Cash Register.

Request Body schema: application/json
object (MetadataRequest) <= 20 properties

You can use this parameter to attach custom key-value data to an object. Metadata is useful for storing additional, structured information on an object.

Note: You can specify up to 20 keys, with key names up to 40 characters long and values up to 500 characters long.

description
string (CashRegisterDescription)

Description of the Cash Register.

Responses

Request samples

Content type
application/json
{}

Response samples

Content type
application/json
{
  • "_id": "1c81cb86-c2e8-4074-afc3-a0601b2bf063",
  • "_type": "CASH_REGISTER",
  • "_env": "TEST",
  • "_version": "1.2.5",
  • "state": "CREATED",
  • "serial_number": "1",
  • "turnover_counter": "-123.45",
  • "description": "My Cash Register 1",
  • "time_creation": 1577833200,
  • "metadata": {}
}

Retrieve a Cash Register

This endpoint returns information about a specific Cash Register.

Authorizations:
JWT
path Parameters
cash_register_id
required
string <uuid> (CashRegisterId) [a-f0-9]{8}-?[a-f0-9]{4}-?4[a-f0-9]{3}-?[89ab...
Example: 1c81cb86-c2e8-4074-afc3-a0601b2bf063

Identifies a Cash Register.

Responses

Response samples

Content type
application/json
{
  • "_id": "1c81cb86-c2e8-4074-afc3-a0601b2bf063",
  • "_type": "CASH_REGISTER",
  • "_env": "TEST",
  • "_version": "1.2.5",
  • "state": "CREATED",
  • "serial_number": "1",
  • "turnover_counter": "-123.45",
  • "description": "My Cash Register 1",
  • "time_creation": 1577833200,
  • "metadata": {},
  • "time_registration": 1577833200,
  • "time_initialization": 1577833200,
  • "initialization_receipt_id": "1c81cb86-c2e8-4074-afc3-a0601b2bf063",
  • "time_decommission": 1577833200,
  • "decommission_receipt_id": "1c81cb86-c2e8-4074-afc3-a0601b2bf063",
  • "time_outage": 1577833200,
  • "time_defect": 1577833200
}

Update a Cash Register

This endpoint updates a Cash Register.

In order to be able to use a Cash Register for signing Receipts it needs to be transitioned to the state INITIALIZED.

Once a Cash Register has eventually reached its end-of-life this has to be reflected by setting its state to DECOMMISSIONED.

Authorizations:
JWT
path Parameters
cash_register_id
required
string <uuid> (CashRegisterId) [a-f0-9]{8}-?[a-f0-9]{4}-?4[a-f0-9]{3}-?[89ab...
Example: 1c81cb86-c2e8-4074-afc3-a0601b2bf063

Identifies a Cash Register.

Request Body schema: application/json
state
required
string
Enum: "REGISTERED" "INITIALIZED" "DECOMMISSIONED" "DEFECTIVE" "OUTAGE"

Responses

Request samples

Content type
application/json
{
  • "state": "INITIALIZED"
}

Response samples

Content type
application/json
{
  • "_id": "1c81cb86-c2e8-4074-afc3-a0601b2bf063",
  • "_type": "CASH_REGISTER",
  • "_env": "TEST",
  • "_version": "1.2.5",
  • "state": "CREATED",
  • "serial_number": "1",
  • "turnover_counter": "-123.45",
  • "description": "My Cash Register 1",
  • "time_creation": 1577833200,
  • "metadata": {},
  • "time_registration": 1577833200,
  • "time_initialization": 1577833200,
  • "initialization_receipt_id": "1c81cb86-c2e8-4074-afc3-a0601b2bf063",
  • "time_decommission": 1577833200,
  • "decommission_receipt_id": "1c81cb86-c2e8-4074-afc3-a0601b2bf063",
  • "time_outage": 1577833200,
  • "time_defect": 1577833200
}

List Cash Registers

This endpoint lists available Cash Registers.

Authorizations:
JWT
query Parameters
order
string
Default: "ASC"
Enum: "ASC" "DESC"

Determines the sorting order.

limit
integer [ 1 .. 100 ]
Default: 100

Limits the number of returned results.

offset
integer >= 0
Default: 0

Skips the specified number of results from the result set.

Responses

Response samples

Content type
application/json
{
  • "data": [
    ],
  • "count": 9007199254740991,
  • "_type": "CASH_REGISTER_LIST",
  • "_env": "TEST",
  • "_version": "1.2.5"
}

Retrieve metadata of a Cash Register

This endpoint retrieves additional structured information about a Cash Register.

Authorizations:
JWT
path Parameters
cash_register_id
required
string <uuid> (CashRegisterId) [a-f0-9]{8}-?[a-f0-9]{4}-?4[a-f0-9]{3}-?[89ab...
Example: 1c81cb86-c2e8-4074-afc3-a0601b2bf063

Identifies a Cash Register.

Responses

Response samples

Content type
application/json
{}

Update metadata of a Cash Register

This endpoint creates or updates additional structured information about a Cash Register.

Authorizations:
JWT
path Parameters
cash_register_id
required
string <uuid> (CashRegisterId) [a-f0-9]{8}-?[a-f0-9]{4}-?4[a-f0-9]{3}-?[89ab...
Example: 1c81cb86-c2e8-4074-afc3-a0601b2bf063

Identifies a Cash Register.

Request Body schema: application/json
<= 20 properties
property name*
additional property
string <= 500 characters

Responses

Request samples

Content type
application/json
{}

Response samples

Content type
application/json
{}

FON

Authenticate FON

The fiscalization process requires interactions with FinanzOnline (FON). This includes registering Cash Registers and Signature Creation Units, validating Receipts, etc. The fiskaly SIGN AT automates all those steps.

Our system communicates with FinanzOnline (FON) in the name of the taxpayer. The taxpayer must create a FinanzOnline Cash Register web service user ("Registrierkassen-Webservice-Benutzer", pages 60-63). Then you must use those credentials to authenticate the taxpayer with FON through this endpoint.

Note: The credentials of this Cash Register Web Service User must be provided only once for authenticating with FON. The Cash Register web service user remains authenticated with FON indefinitely.

Note: You must authenticate with FON before transitioning Signature Creation Units and Cash Registers to INITIALIZED.

Note: For requests requiring our system to communicate with FinanzOnline (FON), any downtime or unavailability of the FinanzOnline (FON) service may impact such requests.

Authorizations:
JWT
Request Body schema: application/json
fon_participant_id
required
string (FonParticipantId) [ 8 .. 12 ] characters [0-9A-Za-z]{8,12}

The "Teilnehmer-Identifikation" part of the FinanzOnline Cash Register Web Service User ("Registrierkassen-Webservice-Benutzer") credential triplet to be provided by the taxpayer.

fon_user_id
required
string (FonUserId) [ 5 .. 12 ] characters

The "Benutzer-Identifikation" part of the FinanzOnline Cash Register Web Service User ("Registrierkassen-Webservice-Benutzer") credential triplet to be provided by the taxpayer.

fon_user_pin
required
string (FonUserPin) [ 5 .. 128 ] characters

The "PIN" part of the FinanzOnline Cash Register Web Service User ("Registrierkassen-Webservice-Benutzer") credential triplet to be provided by the taxpayer.

Responses

Request samples

Content type
application/json
{
  • "fon_participant_id": "stringst",
  • "fon_user_id": "string",
  • "fon_user_pin": "string"
}

Response samples

Content type
application/json
{
  • "fon_participant_id": "stringst",
  • "fon_user_id": "string",
  • "authentication_status": "AUTHENTICATED",
  • "time_authentication": 1577833200
}

Retrieve FON Status

This endpoint can be used to check the status of the FON authentication.

If authentication_status is not AUTHENTICATED then it is necessary that the user reauthenticates with FON using the Authenticate FON endpoint.

Authorizations:
JWT

Responses

Response samples

Content type
application/json
{
  • "fon_participant_id": "stringst",
  • "fon_user_id": "string",
  • "authentication_status": "AUTHENTICATED",
  • "time_authentication": 1577833200
}

Receipts

Validate a Receipt

This endpoint validates a Receipt.

This returns a status representing the outcome of the validation against FinanzOnline, as well as a message explaining the validation result. The validation is performed in a sychronous manner, meaning if FinanzOnline is not available the request might time out.

Authorizations:
JWT
path Parameters
cash_register_id
required
string <uuid> (CashRegisterId) [a-f0-9]{8}-?[a-f0-9]{4}-?4[a-f0-9]{3}-?[89ab...
Example: 1c81cb86-c2e8-4074-afc3-a0601b2bf063

Identifies a Cash Register.

receipt_id
required
string <uuid> (ReceiptId) [a-f0-9]{8}-?[a-f0-9]{4}-?4[a-f0-9]{3}-?[89ab...
Example: 1c81cb86-c2e8-4074-afc3-a0601b2bf063

Identifies a Receipt.

Responses

Response samples

Content type
application/json
{
  • "validation_result": "SUCCESS",
  • "time_validation": 1577833200
}

Sign a Receipt

This endpoint signs a Receipt. Hence, it is the single most important endpoint for day-to-day operations.

The response contains all information that is necessary for augmenting the final receipt which is handed out to the customer:

  1. qr_code_data, which contains the data for the RKSV QR Code to be displayed in a graphical representation,
  2. as well as information that needs to be displayed in textual form: receipt_number, time_signature and cash_register_serial_number,
  3. all raw gross amounts.
Authorizations:
JWT
path Parameters
cash_register_id
required
string <uuid> (CashRegisterId) [a-f0-9]{8}-?[a-f0-9]{4}-?4[a-f0-9]{3}-?[89ab...
Example: 1c81cb86-c2e8-4074-afc3-a0601b2bf063

Identifies a Cash Register.

receipt_id
required
string <uuid> (ReceiptId) [a-f0-9]{8}-?[a-f0-9]{4}-?4[a-f0-9]{3}-?[89ab...
Example: 1c81cb86-c2e8-4074-afc3-a0601b2bf063

Identifies a Receipt.

Request Body schema: application/json
receipt_type
required
string
Default: "NORMAL"
Enum: "NORMAL" "CANCELLATION" "TRAINING"

Specifies the type of receipt to be signed:

  • CANCELLATION: Choose this type if the receipt to be signed cancels or reverses a previously signed receipt.
  • TRAINING: This type is appropriate if the receipt to be signed is being created in the course of a training and is therefore not tax relevant.
  • NORMAL: Choose this default type if the receipt to be signed is neither a CANCELLATION nor a TRAINING.
required
object or object or object (ReceiptSchema) = 1 properties

The receipt data to be signed.

object (MetadataRequest) <= 20 properties

You can use this parameter to attach custom key-value data to an object. Metadata is useful for storing additional, structured information on an object.

Note: You can specify up to 20 keys, with key names up to 40 characters long and values up to 500 characters long.

Responses

Request samples

Content type
application/json
{
  • "receipt_type": "NORMAL",
  • "schema": {
    },
  • "metadata": {}
}

Response samples

Content type
application/json
{
  • "_id": "1c81cb86-c2e8-4074-afc3-a0601b2bf063",
  • "_type": "RECEIPT",
  • "_env": "TEST",
  • "_version": "1.2.5",
  • "receipt_type": "NORMAL",
  • "receipt_number": "42",
  • "time_signature": 1577833200,
  • "cash_register_serial_number": "1",
  • "qr_code_data": "_R1-AT3_dGxx_19_2017-10-24T11:07:32_0,00_0,00_0,00_0,00_0,00_7eti9M9dETz2_5474185F_M8LJDeWizNY=_4CtUHTuHoWvNfY0Ty+K8SuUVPYfZHjkM70/ZzATkb7Oj6G8PNWR6K1vsFWTXg2YsMyYHxVXpGJYEiAn0Uojfzw==",
  • "signed": true,
  • "schema": {
    },
  • "metadata": {},
  • "cash_register_id": "1c81cb86-c2e8-4074-afc3-a0601b2bf063",
  • "signature_creation_unit_id": "1c81cb86-c2e8-4074-afc3-a0601b2bf063",
  • "hints": [
    ]
}

Retrieve a Receipt

This endpoint returns information about a specific Receipt. The Receipt is identified by the receipt_id_or_number path parameter.

Authorizations:
JWT
path Parameters
cash_register_id
required
string <uuid> (CashRegisterId) [a-f0-9]{8}-?[a-f0-9]{4}-?4[a-f0-9]{3}-?[89ab...
Example: 1c81cb86-c2e8-4074-afc3-a0601b2bf063

Identifies a Cash Register.

receipt_id_or_number
required
string (ReceiptIdOrNumber) ([a-f0-9]{8}-?[a-f0-9]{4}-?4[a-f0-9]{3}-?[89a...

Identifies a Receipt either by its receipt_id (e.g., 1c81cb86-c2e8-4074-afc3-a0601b2bf063) or its receipt_number (e.g., 42).

Responses

Response samples

Content type
application/json
{
  • "_id": "1c81cb86-c2e8-4074-afc3-a0601b2bf063",
  • "_type": "RECEIPT",
  • "_env": "TEST",
  • "_version": "1.2.5",
  • "receipt_type": "NORMAL",
  • "receipt_number": "42",
  • "time_signature": 1577833200,
  • "cash_register_serial_number": "1",
  • "qr_code_data": "_R1-AT3_dGxx_19_2017-10-24T11:07:32_0,00_0,00_0,00_0,00_0,00_7eti9M9dETz2_5474185F_M8LJDeWizNY=_4CtUHTuHoWvNfY0Ty+K8SuUVPYfZHjkM70/ZzATkb7Oj6G8PNWR6K1vsFWTXg2YsMyYHxVXpGJYEiAn0Uojfzw==",
  • "signed": true,
  • "schema": {
    },
  • "metadata": {},
  • "cash_register_id": "1c81cb86-c2e8-4074-afc3-a0601b2bf063",
  • "signature_creation_unit_id": "1c81cb86-c2e8-4074-afc3-a0601b2bf063",
  • "hints": [
    ],
  • "fon_validations": [
    ]
}

List all Receipts

This endpoint lists Receipts of all available Cash Registers.

Authorizations:
JWT
query Parameters
order_by
string
Default: "receipt_number"
Value: "receipt_number"

Specifies the property to sort by

receipt_types
Array of strings (ReceiptType)
Items Enum: "NORMAL" "CANCELLATION" "TRAINING" "INITIALIZATION" "DECOMMISSION" "MONTHLY_CLOSE" "YEARLY_CLOSE" "SIGNATURE_CREATION_UNIT_FAULT_CLEARANCE"

Filter to include only specific receipt types.

order
string
Default: "ASC"
Enum: "ASC" "DESC"

Determines the sorting order.

limit
integer [ 1 .. 100 ]
Default: 100

Limits the number of returned results.

offset
integer >= 0
Default: 0

Skips the specified number of results from the result set.

Responses

Response samples

Content type
application/json
{
  • "data": [
    ],
  • "count": 9007199254740991,
  • "_type": "RECEIPT_LIST",
  • "_env": "TEST",
  • "_version": "1.2.5"
}

List Receipts of a Cash Register

This endpoint lists the Receipts of a specific Cash Register.

Authorizations:
JWT
path Parameters
cash_register_id
required
string <uuid> (CashRegisterId) [a-f0-9]{8}-?[a-f0-9]{4}-?4[a-f0-9]{3}-?[89ab...
Example: 1c81cb86-c2e8-4074-afc3-a0601b2bf063

Identifies a Cash Register.

query Parameters
order_by
string
Default: "receipt_number"
Value: "receipt_number"

Specifies the property to sort by

receipt_types
Array of strings (ReceiptType)
Items Enum: "NORMAL" "CANCELLATION" "TRAINING" "INITIALIZATION" "DECOMMISSION" "MONTHLY_CLOSE" "YEARLY_CLOSE" "SIGNATURE_CREATION_UNIT_FAULT_CLEARANCE"

Filter to include only specific receipt types.

order
string
Default: "ASC"
Enum: "ASC" "DESC"

Determines the sorting order.

limit
integer [ 1 .. 100 ]
Default: 100

Limits the number of returned results.

offset
integer >= 0
Default: 0

Skips the specified number of results from the result set.

Responses

Response samples

Content type
application/json
{
  • "data": [
    ],
  • "count": 9007199254740991,
  • "_type": "RECEIPT_LIST",
  • "_env": "TEST",
  • "_version": "1.2.5"
}

Retrieve metadata of a Receipt

This endpoint retrieves additional structured information about a Receipt.

Authorizations:
JWT
path Parameters
cash_register_id
required
string <uuid> (CashRegisterId) [a-f0-9]{8}-?[a-f0-9]{4}-?4[a-f0-9]{3}-?[89ab...
Example: 1c81cb86-c2e8-4074-afc3-a0601b2bf063

Identifies a Cash Register.

receipt_id_or_number
required
string (ReceiptIdOrNumber) ([a-f0-9]{8}-?[a-f0-9]{4}-?4[a-f0-9]{3}-?[89a...

Identifies a Receipt either by its receipt_id (e.g., 1c81cb86-c2e8-4074-afc3-a0601b2bf063) or its receipt_number (e.g., 42).

Responses

Response samples

Content type
application/json
{}

Update metadata of a Receipt

This endpoint creates or updates additional structured information about a Receipt.

Authorizations:
JWT
path Parameters
cash_register_id
required
string <uuid> (CashRegisterId) [a-f0-9]{8}-?[a-f0-9]{4}-?4[a-f0-9]{3}-?[89ab...
Example: 1c81cb86-c2e8-4074-afc3-a0601b2bf063

Identifies a Cash Register.

receipt_id_or_number
required
string (ReceiptIdOrNumber) ([a-f0-9]{8}-?[a-f0-9]{4}-?4[a-f0-9]{3}-?[89a...

Identifies a Receipt either by its receipt_id (e.g., 1c81cb86-c2e8-4074-afc3-a0601b2bf063) or its receipt_number (e.g., 42).

Request Body schema: application/json
<= 20 properties
property name*
additional property
string <= 500 characters

Responses

Request samples

Content type
application/json
{}

Response samples

Content type
application/json
{}

Data Exports

Export a Cash Register

This endpoint returns the DEP7 export data.

You need to provide this data to the authorities during an audit.

Usually a complete DEP7 (i.e., from the first signed receipt to the last signed receipt) needs to be exported. The auditors can also request a subset of the complete export. This partial export can be parametrized with the query parameters.

Authorizations:
JWT
path Parameters
cash_register_id
required
string <uuid> (CashRegisterId) [a-f0-9]{8}-?[a-f0-9]{4}-?4[a-f0-9]{3}-?[89ab...
Example: 1c81cb86-c2e8-4074-afc3-a0601b2bf063

Identifies a Cash Register.

query Parameters
start_receipt_number
string[0-9]+
Example: start_receipt_number=42

Only return receipts with a receipt_number greater than or equal to the given value.

end_receipt_number
string[0-9]+
Example: end_receipt_number=42

Only return receipts with a receipt_number less than or equal to the given value.

start_time_signature
integer [ 0 .. 9007199254740991 ]
Example: start_time_signature=1577833200

Only return receipts with a time_signature later than or equal to the given timestamp.

end_time_signature
integer [ 0 .. 9007199254740991 ]
Example: end_time_signature=1577833200

Only return receipts with a time_signature earlier than or equal to the given timestamp.

Responses

Response samples

Content type
application/json
{
  • "Belege-Gruppe": [
    ]
}

Configurations

Update organization's configuration

This endpoint updates current Configuration for an Organization

Authorizations:
JWT
Request Body schema: application/json
yearly_receipt_validation_enabled
boolean
monthly_receipt_validation_enabled
boolean

Responses

Request samples

Content type
application/json
{
  • "yearly_receipt_validation_enabled": true,
  • "monthly_receipt_validation_enabled": true
}

Response samples

Content type
application/json
{
  • "_env": "TEST",
  • "_version": "1.2.5",
  • "yearly_receipt_validation_enabled": true,
  • "monthly_receipt_validation_enabled": true,
  • "revision": 0
}

Retrieve organization's configuration

This endpoint retrieves the current Configuration for an Organization.

Authorizations:
JWT

Responses

Response samples

Content type
application/json
{
  • "_env": "TEST",
  • "_version": "1.2.5",
  • "yearly_receipt_validation_enabled": true,
  • "monthly_receipt_validation_enabled": true,
  • "revision": 0
}

Was this page helpful?