--- updatedAt: 2026-04-21T18:06:49.000Z agentTools: projectIndex: https://docs.confirmo.net/llms.txt --- # Create Take Request for expired Invoice Places a Take Request for an Invoice that has expired. A Take Request is a process that allows accepting an underpaid Invoice as paid after its expiration. # OpenAPI definition ````json { "components": { "schemas": { "ErrorResource": { "properties": { "errors": { "items": { "$ref": "#/components/schemas/ErrorTo" }, "type": "array" } }, "type": "object" }, "ErrorTo": { "properties": { "message": { "type": "string" }, "requestId": { "type": "string" }, "type": { "type": "string" } }, "type": "object" }, "TakeInfoTo": { "properties": { "customerCurrency": { "description": "The currency in which the customer is supposed to pay.", "example": "LTC", "type": "string" }, "expiration": { "description": "The timestamp when take offer expires.", "example": 1552987955, "format": "int64", "type": "integer" }, "expirationDuration": { "description": "The number of seconds before take offer expires.", "example": 120, "format": "int64", "type": "integer" }, "merchantCurrency": { "type": "string" }, "offeredAmountInMerchantCurrency": { "type": "number" }, "offeredPrice": { "description": "The new price of crypto currency.", "example": "1318.16", "type": "number" }, "offeredSettlementAmount": { "description": "The new amount to be settled (after take).", "example": 3198, "type": "number" }, "originalSettlementAmount": { "description": "The original amount to be settled (before take)", "example": "4505.4", "type": "number" }, "refundAmount": { "description": "Used for internal purposes", "example": 0, "type": "number" }, "settlementCurrency": { "description": "The currency of the Settlement Method.", "example": "EUR", "type": "string" }, "taken": { "description": "True if the Invoice was taken.", "example": true, "type": "boolean" }, "takenAt": { "description": "The take action timestamp as Unix timestamp.", "example": 1552987719, "format": "int64", "type": "integer" } }, "type": "object" } }, "securitySchemes": { "bearer-auth": { "scheme": "bearer", "type": "http" } } }, "info": { "description": "_Confirmo merchant API_ consists of the APIs for the Merchant communication with the Confirmo.com service.\n\n**Be sure to use HTTPS protocol.** All API requests are redirected to HTTPS, thus most of the plain HTTP requests won't\nwork (those using PUT, POST, or PATCH methods).\n\n**Please be aware that this API is subject to change.** Confirmo can add some new fields. Please, remember that when\nwriting your clients. Your client is required to ignore any fields it does not know.\n\n## Authentication\n\nCurrently, this API supports only one model of authentication - _API keys_. The keys are private for every merchant and\nshould only be used to access your invoices and settlements from the outside of the user interface.\n\n#### API key management\n\nAPI keys can be created and deleted in the user interface. After you log in to your account, navigate to `Settings` and\ncontinue to the `API Keys` section. The new key\nwill be\ncreated and its token will be displayed for a limited time. Make sure to store it in a __safe__ place as it\nwill not be accessible via the UI for security reasons later.\n\nEach token will provide read/write access outside the UI to your account. It will remain valid until its\ndeletion in the UI.\n\n#### API key best practices\n\nWhen you use API keys in your applications, keep them secure.\n\nPublicly exposing your credentials can result in your account being compromised.\n\nTo keep your API keys secure, follow these best practices:\n\n* __Do not embed API keys directly in code__: API keys embedded in code can be accidentally exposed to the\n public. For example, if you forget to remove the keys from the code that you share. Instead of embedding your API keys\n in your applications, store them in environment variables or files outside your application's source tree.\n\n\n* __Do not store API keys in files inside your application's source tree__: If you store API keys in files, keep the\n files outside your application's source tree to help ensure your keys do not end up in your source code control\n system. This is particularly important if you use a public source code management system such as GitHub.\n\n\n* __Restrict your API keys to IP addresses that need them__: By restricting the IP addresses that\n can use each key, you can reduce the impact of a compromised API key.\n\n\n* __Delete unneeded API keys__: To minimize your exposure to attack, delete any API keys that you no longer need.\n\n\n* __Review your code before publicly releasing it__: Ensure that code does not contain API keys or any other\n private information before you make your code publicly available.\n\n#### API key usage\n\nEach request made from the outside of the application must include an `Authorization` header containing a valid API key\ntoken. Example using curl:\n\n
\n  \n    curl https://confirmo.net/api/v3/invoices -H 'Authorization: Bearer {YOUR_API_KEY}' \n  \n
\n\n## Status codes\n\nAPI responses are marked with status codes:\n\n* `200 OK` Request resolved\n\n\n* `201 Created` Request resolved by successfully creating a new object in the\n system\n\n\n* `204 No Content` Request resolved and no content is returned\n\n\n* `400 Bad Request` Invalid format of request\n\n\n* `401 Unauthorized` Invalid or missing API key in the request header\n\n\n* `403 Forbidden` Authorized but not to access the particular resource\n\n\n* `500 Internal Server Error` The server has encountered an unexpected\n condition; please contact support@confirmo.net\n\n\n* `503 Service Unavailable` The server could not fulfill your request;\n please contact the Confirmo support\n\n## Idempotent requests\n\nSelected endpoints accept an optional `Idempotency-Key` request header to prevent duplicate transactions in \ncases such as retries caused by network issues or delays. Endpoints that support it note `Idempotency-Key`\nsupport in their description.\n\nWhen you supply the header, the value must be a non-empty, printable-ASCII string of at most 255 characters. \nWe recommend generating a fresh UUID for each logical operation.\n\nUsing the same idempotency key for multiple requests ensures that only the outcome of the original request is ever \nreturned. Confirmo saves the first response and reuses it for any subsequent requests with that same key, without \nre-executing the operation. Note that when the request failed, you will have the original error \nresponse available only on the first call, on the retry with same idempotency key only a generic `409` + \n`idempotency_key_previously_failed`.\n\nThe stored response remains available for 24 hours. After that period a new idempotency key must be used.\n\nError responses all share the shape `{ \"message\": ..., \"error\": ... }`, where `error` is a stable machine-readable code.\n\n`400 Bad Request` — the supplied key is malformed (empty, longer than 255 characters, or containing\nnon-printable-ASCII characters):\n\n```json\n{\n \"message\": \"Idempotency-Key must be non-empty, at most 255 printable-ASCII characters.\",\n \"error\": \"idempotency_key_invalid\"\n}\n```\n\n`409 Conflict` — the same key was already used with different request parameters (body or query):\n\n```json\n{\n \"message\": \"This Idempotency-Key was already used with different request parameters (body or query).\",\n \"error\": \"idempotency_key_reused_with_different_body\"\n}\n```\n\n`409 Conflict` — the same key was already used on a different endpoint:\n\n```json\n{\n \"message\": \"This Idempotency-Key was already used on a different endpoint.\",\n \"error\": \"idempotency_key_reused_on_different_endpoint\"\n}\n```\n\n`409 Conflict` — a request with this key is still being processed:\n\n```json\n{\n \"message\": \"A request with this Idempotency-Key is still being processed.\",\n \"error\": \"idempotency_key_in_progress\"\n}\n```\n\n`409 Conflict` — the original request with this key failed; retry with a new key:\n\n```json\n{\n \"message\": \"The original request with this Idempotency-Key failed, retry with a new Idempotency-Key.\",\n \"error\": \"idempotency_key_previously_failed\"\n}\n```\n\n## Notifications\n\nThe _Confirmo merchant API_ allows merchants to enable simple notifications as part of invoice creation. These\nnotifications are of the following types:\n\n* [webhook notifications](#webhook-notifications)\n* [e-mail notifications](#email-notifications)\n\nNotifications are sent on the following occasions:\n\n1. invoice creation;\n2. change of invoice status;\n3. received payment/outgoing payment (refund).\n\n### Webhook notifications\n\nIf `notifyUrl` is defined in an invoice creation request, then the system tries to send an HTTP `POST` request\nwith `Content-Type` set to `application/json` to the URL. The request's body contains the current invoice model (same as\ncreating a new invoice response).\n\nBy default, the system will continue to send the notification until it receives `200` response or stops after 20 tries.\nAfter the first failed try it will wait for 1 second. The waiting period is doubled after each failed request.\n\nIf the system fails to send a successful request, it will try to send an error report via e-mail. It is sent\non `notifyEmail` if it was specified or on the merchant's user e-mail otherwise. This e-mail contains our error message\nand error response to the last unsuccessful request.\n\n#### Callback Password\n\n__A callback password__ is an autogenerated pseudo-random alphanumeric string used as a data validation mechanism for\nstronger security. When a callback password is created, it is used to generate signatures that are included in\nevery webhook notification **request header**.\n\nThe signature is generated - and **needs to be validated** (to ensure that the webhooks do originate from Confirmo and\nwere not forged by someone else) - by\n\n1. taking the request/response body;\n\n2. suffixing it with the callback password;\n\n3. hashing the result using the SHA256 algorithm;\n\n4. storing the hexadecimal representation in the `bp-signature` header field of the request/response.\n\n##### Example\n\n- Callback password: `azLlmIpWHM9NJbMe`\n\n\n- Response body:\n `{\"address\":\"P3n6Ul5FsSd59xfbzdD2VN3HHycIddjpc\",\"cryptoUri\":\"bitcoin:P3n6Ul5FsSd59xfbzdD2VN3HHycIddjpc?amount=0.00779057\",\"createAtTime\":1509525927,\"serverTime\":1509525927,\"timeoutTime\":1509526226,\"id\":\"inv57dkwrrdw\",\"url\":\"https://pay.confirmo.com/public/invoice/inv57dkwrrdw\",\"reference\":\"{\\\"customerEmail\\\":\n \\\"customer@example.com\\\", \\\"orderNumber\\\": 123, \\\"customerName\\\": \\\"Customer\n Name\\\"}\",\"returnUrl\":\"http://yourEShop.com/thankYourForYourOrder\",\"notifyUrl\":\"https://yourEShop.com/orderReceived\",\"notifyEmail\":\"notify@email.com\",\"product\":{\"name\":\"pName\",\"description\":\"pDesc\"},\"status\":\"active\",\"rate\":{\"currency\":\"EUR\",\"currencyX\":\"BTC\",\"rate\":\"6418.02\"},\"txids\":[],\"invoice\":{\"amount\":\"50.00\",\"currency\":\"EUR\"},\"crypto\":{\"amount\":\"0.00779057\",\"currency\":\"BTC\"},\"invoiceSettlements\":[],\"refunds\":[],\"paid\":{\"amount\":\"0.00000000\",\"currency\":\"BTC\",\"diff\":\"-0.00779057\"},\"flags\":{\"split\":false,\"autoUnderpayment\":false,\"refundable\":false},\"paidAtTime\":0,\"completedAtTime\":0,\"settlementMethodCurrency\":\"CZK\",\"confirmations\":0,\"requiredConfirmations\":2,\"exception\":[]}`\n\n\n- SHA256\n **\n input**:`{\"address\":\"P3n6Ul5FsSd59xfbzdD2VN3HHycIddjpc\",\"cryptoUri\":\"bitcoin:P3n6Ul5FsSd59xfbzdD2VN3HHycIddjpc?amount=0.00779057\",\"createAtTime\":1509525927,\"serverTime\":1509525927,\"timeoutTime\":1509526226,\"id\":\"inv57dkwrrdw\",\"url\":\"https://pay.confirmo.com/public/invoice/inv57dkwrrdw\",\"reference\":\"{\\\"customerEmail\\\":\n \\\"customer@example.com\\\", \\\"orderNumber\\\": 123, \\\"customerName\\\": \\\"Customer\n Name\\\"}\",\"returnUrl\":\"http://yourEShop.com/thankYourForYourOrder\",\"notifyUrl\":\"https://yourEShop.com/orderReceived\",\"notifyEmail\":\"notify@email.com\",\"product\":{\"name\":\"pName\",\"description\":\"pDesc\"},\"status\":\"active\",\"rate\":{\"currency\":\"EUR\",\"currencyX\":\"BTC\",\"rate\":\"6418.02\"},\"txids\":[],\"invoice\":{\"amount\":\"50.00\",\"currency\":\"EUR\"},\"crypto\":{\"amount\":\"0.00779057\",\"currency\":\"BTC\"},\"invoiceSettlements\":[],\"refunds\":[],\"paid\":{\"amount\":\"0.00000000\",\"currency\":\"BTC\",\"diff\":\"-0.00779057\"},\"flags\":{\"split\":false,\"autoUnderpayment\":false,\"refundable\":false},\"paidAtTime\":0,\"completedAtTime\":0,\"settlementMethodCurrency\":\"CZK\",\"confirmations\":0,\"requiredConfirmations\":2,\"exception\":[]}azLlmIpWHM9NJbMe`\n\n\n- SHA256 **output** as a hex string (and the value of the `bp-signature`\n header field):\n `08468c5b3af81ca14fe5a3b40703773175cba2cc3ef8700e62e943edd4cba3ee`\n\n##### Creating/Deleting\n\nTo create a callback password, use *Security\nSettings* in\nMerchant UI.\n\nMerchant can create only one callback password. A unique callback password is generated every time and\nbecomes active right away.\n\nDeleting the callback password deactivates the mechanism (`BP_SIGNATURE` is no longer included).\n\n#### Final Status Check\n\n**It is not recommended to rely on webhook data only.** In case that callback password gets compromised, an attacker\nwould still be able to forge the webhooks. Therefore, after receiving a webhook about reaching a final status of an\nentity (such as `paid` status for invoice), it's advised to cross-check the result by invoking Confirmo API endpoint\nfor getting details of the entity (such as GET invoice endpoint). This is\nthe ultimate source of truth even in case that somebody managed to forge the webhook.\n\n### Email notifications\n\nThe system supports two types of email notifications in invoice creation request, each serving a different purpose:\n\n#### Merchant Notifications (`notifyEmail`)\n\n - Sends basic invoice information in human-readable format to the specified email address\n - Notification are sent:\n - When HTTPS notifications fail (see above)\n - When invoice payment is successful\n - When invoice expires and enters exception state\n - **Important**: Do not use customer email addresses here, as those notifications may contain merchant-specific information\n\n#### Customer Notifications (`customerEmail`)\n - Notifies customers about important invoice status changes:\n - When invoice payment is successful\n - When invoice expires and enters exception state\n - Should contain the end-customer's email address only\n - Note that the customer email can be set also by end-customer on the public invoice when the invoice is in Confirming state\n\n## Entity states\n\n### Invoice\n\n![Invoice state diagram](https://confirmo-test.s3.eu-central-1.amazonaws.com/Invoice-diagram.svg)\n\n- `prepared` - customer selects preffered payment method.\n Status `prepared` exists only if the [Create invoice](#/Invoice/createInvoiceByMerchant\") endpoint\n is called with parameter `invoice.currencyTo= null`, otherwise the end-customer will not be able to select crypto of\n their choice. It enters `active` state, or `expired` state after 15 minutes of inactivity.\n - next states: `active`, `expired`\n\n- `active` - Invoice with payment instructions including crypto address, crypto asset, crypto network, amount,\n currency... By default, the invoice is active for 15 min. Expiration time can be adjusted\n from *Invoice Settings*.\n - next states: `expired`, `confirming`\n\n- `expired` - No payment has been sent within its active period or the amount sent is smaller than the\n requested amount. An `expired` invoice may have a so-called `exception` [flag](#exception).\n - final state for invoices with [exception flag](#exception) set to `false`.\n - next state: `paid` for invoices with [exception flag](#exception) set to `true` and were accepted/taken\n by the merchant.\n\n- `confirming` - payment detected, the amount is correct or higher, but the payment is not finished (usually it means it\n has not enough confirmations) on its crypto network yet\n - next states: `error`, `paid`\n\n- `error` - confirming failed. Transaction is not confirmed within next 96 hours.\n - final state\n\n- `paid` - the invoice has been credited to the merchant's account and has sufficient confirmation(s).\n - final state\n\n#### Exception\n\n`unhandledExceptions` is a special flag informing merchants about an invoice that may need attention.\n\n`unhandledExceptions` set to `true` indicates the invoice is **overpaid**, **underpaid** or **incorrect amount** has\nbeen sent to an `expired` invoice.\n\nInvoices with `unhandledExceptions = true` share the following behavior:\n\n1. Invoices are refundable from invoice `url`. However, only paying customer is allowed to request a refund from\n invoice `url` for security reasons. Merchant can initiate refund from invoice detail in his dashboard.\n\n2. `paid` invoice. Only overpayment and not the whole amount is refundable. Invoice remains in state `paid` all time.\n\n\n3. `expired` invoice. The whole amount is refundable. The merchant can review the invoice and accept the payment to his\n balance additionally. Once the payment is credited to merchant's balance the status of the invoice changes to `paid`.\n The invoice is no longer refundable and `unhandledExceptions` is set to `false`.\n\n4. If the additional payment is sent to resolved (already refunded or credited) invoice `unhandledExceptions` is set\n to `true` again.\n\n\n5. We do not mark invoices with an exception flag if the amount of overpayment or underpayment is very low and the\n refunding amount would cost more than the network fee or very close to the network fee.\n\n\n6. Payment that matches rules specified in Dashboard\n in [Underpayment threshold](https://dashboard.confirmo.com/platform/settings/invoice) have `unhandledExceptions` set\n to `false`.\n\n#### Data Purging\n\nPlease note that invoices which transition directly from `prepared` to `expired` status (i.e. those which never had\ntheir `customerCurrency` (or more generally payment method) set) are subject to data purging after some retention\nperiod (e.g. a year).\n\n### Payout\n\n![Payout state diagram](https://confirmo-test.s3.eu-central-1.amazonaws.com/Payout-diagram.svg)\n\n- `prepared` - new payout\n - next states: `confirmed`, `expired`\n\n- `confirmed` - Exchange rate has been accepted by a merchant\n - next state: `sending`\n\n- `sending` - payout prepared to be sent. Payouts are sent on a regular basis\n - next state: `done`\n\n- `done` - payment was successful and txid is known\n - final state\n\n- `expired` - payout that has not been `confirmed` in given time.\n - final state\n\n#### Data Purging\n\nSimilar to invoices, payouts which transition directly from `prepared` to `expired` status are subject to data purging\nafter some retention period (e.g. a year).\n\n## Overlay - no redirection to confirmo.com website\n\nTo open an invoice in the overlay instead of redirecting the user to our page.\nFollow these steps in the [library](https://www.npmjs.com/package/@confirmo/overlay) documentation.\n\n## Integration tips\n\n- If the notification is not received, please check that `notifyUrl` is specified correctly, a valid SSL certificate is\n installed on your server and the `notifyUrl` starts with https:// not http://. Verify your notification handler\n script is receiving POST's.\n\n\n- Once your notification handler receives a response, especially when `paid` status is announced, it is recommended to\n call [Get invoice detail](#/Invoice/getInvoiceByMerchant) to verify\n notification data.\n\n\n- It is not recommended to rely on [webhook notification](#webhook-notifications) POST's data only.\n\n\n- Please make sure, that the payment URL is not public nor available for search engines.\n\n\n- It is possible to request a refund via payment URL if the payment was sent incorrectly, so please be very cautious and\n consider security. Even your support staff can request a refund via payment URL.\n\n## Invoice creation\n\nWhen [creating a new invoice](#/Invoice/createInvoiceByMerchant), the following parameters are the most important ones.\n\n| Parameter name | Required | Description | Example | Dedicated Section |\n|------------------------|----------|--------------------------------------|---------|-------------------------------------------------------|\n| `invoice.amount` | Yes | The original invoice's amount | 100 | [Invoice original amount](#invoice-original-amount) |\n| `invoice.currencyFrom` | Yes | Code of the original invoice's asset | USD | [Invoice original amount](#invoice-original-amount) |\n| `invoice.currencyTo` | No | Code of the payment asset | BTC | [Invoice payment asset](#invoice-payment-asset) |\n| `settlement.currency` | Yes* | Code of the settlement asset | EUR | [Invoice settlement asset](#invoice-settlement-asset) |\n\n* Technically, it's `settlement` (not `settlement.currency`) attribute which is required, i.e. sending a request\nwith an empty `settlement` attribute is also valid (and it's equivalent to sending a request\nwith `settlement.currency = null`).\n\n### Invoice original amount\n\nParameter `invoice.currencyFrom` (code of the original invoice's asset) can be set to almost any world fiat currency\n(`USD`, `EUR`, `CHF`, … ) and also to `BTC`, please refer to [Get assets endpoint](#/Assets/getAssets) to get\nlist of the currently supported assets (those with `merchantAsset=true`).\n\n### Invoice payment asset\n\nParameter `invoice.currencyTo` is highly recommended to be set to _null_. If set to _null_, the invoice is created and\nthe status of the invoice is set to **prepared**, which allows the customer to select any supported payment methods.\nSupported payment methods can be enabled/disabled in the dashboard.\n\nIt's also possible to set it to:\n\n* `BTC` to pre-select payment via native Bitcoin\n* `BTC` (alongside with parameter `invoice.layer2ProtocolName` set to `LIGHTNING`) to pre-select payment via Bitcoin\n Lightning\n* `LTC` to pre-select payment via native Litecoin\n\nShould you need to create an invoice with other predefined payment method, please contact us at _tech@confirmo.net_.\n\n### Invoice settlement asset\n\nParameter `settlement.currency` configure s the settlement asset in which we credit merchant balance. There are two main\noptions to choose from described in the following subsections.\n\n#### Without conversion (Keep in kind)\n\nIf you set `settlement.currency = null` when creating an Invoice, all the payments sent to the Invoice will be credited\nto the merchant account in the same crypto asset as the customer used for the payment. For instance, if the customer\nchooses to pay with TRX, the payment will be credited to the merchant's TRX balance.\n\n#### With conversion\n\nYou can choose in which asset you want to be credited; to do so, use `settlement.currency = `.\nIn this case, all the payments to the Invoice will be converted to the settlement asset you set.\n\nCurrently, we support the following settlement assets:\n\n| `settlement.currency` | Asset name | Asset type |\n|-----------------------|------------------------|---------------------|\n| BTC | Bitcoin | Crypto |\n| CZK | Czech koruna | Fiat |\n| EUR | Euro | Fiat |\n| GBP | British pound sterling | Fiat |\n| HUF | Hungarian forint | Fiat |\n| PLN | Polish zloty | Fiat |\n| USD | United States dollar | Fiat |\n| USDC | USD Coin | Crypto (stablecoin) |\n| USDT | Tether USD | Crypto (stablecoin) |\n\n### Sample combinations\n\n| `invoice.currencyFrom` | `invoice.currencyTo` | `invoice.layer2ProtocolName` | `settlement.currency` | Description |\n|------------------------|----------------------|------------------------------|-----------------------|--------------------------------------------------------------------------------------|\n| `USD` | _null_ | | `EUR` | USD invoice to be paid by a customer-chosen method and credited in EUR |\n| `GBP` | _null_ | | `USDC` | GBP invoice to be paid by a customer-chosen method and credited in USDC |\n| `BTC` | `BTC` | `LIGHTNING` | `USDT` | BTC invoice to be paid by Bitcoin Lightning and credited in USDT |\n| `EUR` | _null_ | | _null_ | EUR invoice to be paid by a customer-chosen method and credited in the payment asset |\n| `CHF` | `LTC` | | `BTC` | CHF invoice to be paid by Litecoin and credited in BTC |\n\n## Developers\n\n### Postman\n\nWhen you have downloaded [the OpenAPI specification](./confirmo-api.json), you can import it\nto [Postman](https://www.postman.com/).\nThe tool will generate all the endpoints and code snippets, which you could use in your application.\n\n\n\n### Swagger tools\n\nIf you insert the downloaded OpenAPI specification into [Swagger editor](https://editor.swagger.io/), you could then\ngenerate a Client SDK that you will be able to use for integration Confirmo API into your application. You can use\n[Swagger Codegen](https://github.com/swagger-api/swagger-codegen)\nor [OpenAPI Generator](https://openapi-generator.tech/) too.\n", "title": "Confirmo API", "version": "2.0" }, "openapi": "3.1.0", "paths": { "/v3/invoices/{id}/take": { "post": { "description": "Places a Take Request for an Invoice that has expired. A Take Request is a process that allows accepting an underpaid Invoice as paid after its expiration.", "operationId": "placeTakeRequest", "parameters": [ { "description": "The Invoice ID", "example": "invz75dnkdk4", "in": "path", "name": "id", "required": true, "schema": { "type": "string" } } ], "responses": { "200": { "content": { "application/json": { "schema": { "$ref": "#/components/schemas/TakeInfoTo" } } }, "description": "Take request successfully created" }, "400": { "content": { "*/*": { "schema": { "$ref": "#/components/schemas/ErrorResource" } } }, "description": "Bad Request" }, "403": { "content": { "*/*": { "schema": { "$ref": "#/components/schemas/ErrorResource" } } }, "description": "Forbidden" }, "409": { "content": { "*/*": { "schema": { "$ref": "#/components/schemas/ErrorResource" } } }, "description": "Conflict" } }, "summary": "Create Take Request for expired Invoice", "tags": [ "Invoice" ] } } }, "security": [ { "bearer-auth": [ "read", "write" ] } ], "servers": [ { "url": "https://confirmo.net/api" } ], "tags": [ { "description": "Invoice endpoints", "name": "Invoice" } ], "x-readme": { "proxy-enabled": false } } ````