# The anybill API > **Integrating with an AI coding agent or chat assistant?** anybill provides > machine-readable documentation, a Vendor API `llms.txt` and a ready-to-use > `AGENTS.md` file for POS integrations. See > [AI-Assisted Integration](./ai_assisted_integration.md). ## Getting Started For integrating anybill into a POS software system a few simple steps are required: 1. Have a look at the legal requirements
For information about legal requirements click here. 2. Integrate authentication
Each POS software provider receives a clientId assigned to him and credentials for every vendor. Have a look at the authentication documentation for more information. 3. Integrate the Bill endpoint
There are four options for sending bills digitally: 4. Create a Screen for showing the receipt with a QR Code on a customer display
Note the Template for the Customer Display. 5. Integrate Store Management
To automatically manage and sync all stores of an vendor the Store API can be used. 6. Integration Review
After finishing the integration, anybill will review it.
More information about the review ## Retry Policy Guidelines To ensure the reliable and consistent delivery of digital receipts, we recommend that all partners implement a robust retry policy when interacting with our API. This policy helps manage temporary network issues and ensures that receipts are processed successfully. ### When to Retry Every status code an endpoint can return, together with the retry decision for it, is listed in a **Status codes** table on the respective endpoint page ([Bill](https://developer.anybill.de/vendor_api/bill_endpoints.html#status-codes), [Store](https://developer.anybill.de/vendor_api/store_endpoints.html#status-codes), [Loyalty](https://developer.anybill.de/vendor_api/loyalty_endpoints.html#status-codes)). Those tables follow one common rule set: | Class | Meaning | Action | | --- | --- | --- | | **2xx** | The request was processed. | Done. Do not resend. | | **401** | Access token missing, expired or invalid. | **Do not back off.** Refresh the token (or re-authenticate) once and resend the same request. A second 401 is a credentials problem – stop and alert. | | **Other 4xx** (400, 403, 404, 409) | The request itself is wrong: invalid payload, missing scope or permission, unknown resource, or the operation was already performed. | **Do not retry.** Log the response body including its `traceId`, fix the payload or configuration. A 409 means the earlier attempt succeeded – treat it as done. | | **5xx** (500, 502, 503, 504) | Temporary problem on the anybill side or in front of it. anybill uses 504 when a write could not be completed in time; the request had no effect. | **Retry** with exponential backoff, resending the identical request. | | Network error / timeout | No response received; the request may or may not have reached anybill. | **Retry** with exponential backoff, resending the identical request. | The API does not use 429 (Too Many Requests); do not build client-side throttling around it. ### Retry Strategy - **Exponential Backoff with Jitter:** - Start with a **base delay** of 1 second. - Use an **exponential backoff** formula: `wait_time = base_delay * (2^retry_attempt) * random(0.5, 1.5)`. - Cap the **maximum delay** at 30 seconds. - Retry up to **3 to 5 times** before logging the final failure. ### Idempotency Ensure that all requests you retry are idempotent, meaning that multiple retries of the same request must not result in duplicate resources or inconsistent state. Send every retry with the same identifiers as the first attempt; the endpoint pages describe how each endpoint behaves when it receives the same request twice (for receipts, see [Bill Endpoints](https://developer.anybill.de/vendor_api/bill_endpoints.html#status-codes)). ### Logging We recommend logging each retry attempt, capturing the response status code, the time of the attempt, and the reason for the retry. This will assist in troubleshooting and improving integration reliability. By following these guidelines, you can help ensure smooth and efficient interaction with our API, minimizing disruptions and enhancing the overall user experience. ## Postman A Postman collection can be found here. There are also Environments for Staging and Production To acquire an access_token first set your credentials for the following collection variables: - username - password - client_id After your credentials are set, send a request with the `GetToken` request. The acquired access token will automatically be set for all requests in the collection. Choose the environment and you are good to go. ## License The anybill vendor API v3 data model builds upon the DFKA e.V. EKaBS-Json-Scheme. This scheme is licenced under the Creative Commons Licence CC BY-SA 4.0. This results in the following rights for the user: The EKaBS-JSON schema and the documentation may be reproduced, redistributed, modified and used in any form as long as the reference to the DFKA e.V. as licensor is kept and modifications are only passed on under the same conditions.