> ## Documentation Index > Fetch the complete documentation index at: https://developers.cubbo.com/llms.txt > Use this file to discover all available pages before exploring further. # Attach NF-e invoices issued through Cubbo's fiscal integration > Brazil only. Registers one or more NF-e (Nota Fiscal Eletronica, the Brazilian electronic invoice) that were issued for this order through Cubbo's fiscal integration. Cubbo then fetches the authorized XML and DANFE for each invoice from the fiscal provider and attaches them to the order so the warehouse can print them and ship. Use this when your store issues NF-e through Cubbo's integrated fiscal provider and you need to tell Cubbo which invoices belong to the order. - The order must be in `pending`, `processing`, `picking` or `packing`; otherwise the request is rejected with 422. - Each invoice needs its 44-digit access key (`key`), the identifier you used when issuing it (`identifier`), a `purpose`, the operation type (`SAIDA` outgoing / `ENTRADA` incoming) and the operation nature (`operation_nature`, the CFOP description such as "Venda de mercadoria"). - Keys and identifiers must be unique within the request. If one of the keys already exists in Cubbo, no new invoice is created: Cubbo refreshes the existing invoices from the fiscal provider and responds with `update_invoice_ids` listing those keys. - An identifier that already belongs to a non-cancelled invoice is rejected. Identifiers of cancelled invoices can be reused. - Invoices are created as `PREAPPROVED` and move to `APPROVED` once the fiscal provider confirms them. Read their status in the `invoices` array of `GET /orders`. - Only `invoice_type` `WEBMANIA` is accepted today. ## OpenAPI ````yaml /openapi.yaml post /orders/{order_id}/attach-invoice openapi: 3.1.0 info: title: Cubbo Clients API version: '1.0' summary: >- Orders, inventory, replenishments, returns, shipping and webhooks for Cubbo fulfillment. description: > The Cubbo Clients API connects your store, ERP or marketplace with Cubbo's fulfillment network. All endpoints except `POST /auth/token` require a bearer token; see the Authentication guide. Request and response bodies are JSON. Errors are JSON objects with an `error` key. contact: name: Cubbo integrations email: integraciones@cubbo.com servers: - url: https://api.cubbo.com/v1 description: Production security: - bearerAuth: [] tags: - name: Authentication description: Exchange client credentials for a bearer token. - name: Orders description: Create, update, hold, cancel and read sales orders. - name: Shipping labels description: Read the shipping labels generated for an order. - name: Inventory description: Products and stock per store. - name: Lots description: Lot-level inventory for products with expiration or batch tracking. - name: Reports description: Bulk reports for reconciliation. - name: Replenishments description: Inbound shipments to the warehouse. - name: Returns description: Returns and exchanges. - name: Stores description: Store provisioning and settings. - name: Shipping methods description: Available shipping methods, coverage and quotes. - name: Click and collect description: Pickup points and in-store pickup orders. paths: /orders/{order_id}/attach-invoice: post: tags: - Orders summary: Attach NF-e invoices issued through Cubbo's fiscal integration description: > Brazil only. Registers one or more NF-e (Nota Fiscal Eletronica, the Brazilian electronic invoice) that were issued for this order through Cubbo's fiscal integration. Cubbo then fetches the authorized XML and DANFE for each invoice from the fiscal provider and attaches them to the order so the warehouse can print them and ship. Use this when your store issues NF-e through Cubbo's integrated fiscal provider and you need to tell Cubbo which invoices belong to the order. - The order must be in `pending`, `processing`, `picking` or `packing`; otherwise the request is rejected with 422. - Each invoice needs its 44-digit access key (`key`), the identifier you used when issuing it (`identifier`), a `purpose`, the operation type (`SAIDA` outgoing / `ENTRADA` incoming) and the operation nature (`operation_nature`, the CFOP description such as "Venda de mercadoria"). - Keys and identifiers must be unique within the request. If one of the keys already exists in Cubbo, no new invoice is created: Cubbo refreshes the existing invoices from the fiscal provider and responds with `update_invoice_ids` listing those keys. - An identifier that already belongs to a non-cancelled invoice is rejected. Identifiers of cancelled invoices can be reused. - Invoices are created as `PREAPPROVED` and move to `APPROVED` once the fiscal provider confirms them. Read their status in the `invoices` array of `GET /orders`. - Only `invoice_type` `WEBMANIA` is accepted today. operationId: attachOrderInvoice parameters: - name: order_id in: path required: true schema: type: integer description: Cubbo ID of the order. example: 987654 requestBody: required: true content: application/json: schema: type: object required: - invoices properties: invoice_type: type: string enum: - WEBMANIA default: WEBMANIA description: >- Fiscal provider the invoices were issued with. Only `WEBMANIA` is supported. example: WEBMANIA invoices: type: array minItems: 1 description: Invoices to attach to the order. items: type: object required: - key - identifier - purpose - operation_type - operation_nature properties: key: type: string pattern: ^[0-9]{44}$ description: >- The 44-digit NF-e access key (chave de acesso). Digits only. example: '00000000000000000000000000000000000000000000' identifier: type: string description: >- The identifier used when the invoice was issued with the fiscal provider. Must be unique. example: SALE987654 purpose: type: string description: >- What the invoice documents. Replenishment and unidentified-return purposes are not accepted on orders. enum: - SALE_INVOICE - DONATION_INVOICE - SYMBOLIC_RETURN_INVOICE - DONATION_RETURN_INVOICE - RETURN_INVOICE - REMOVE_STOCK_INVOICE - REMOVE_DAMAGED_STOCK_INVOICE - REMOVE_EXPIRED_STOCK_INVOICE - REMOVE_LOST_STOCK_INVOICE - SHIPPING - SHIPPING_RETURN - SHIPPING_COMPLEMENT - SHIPPING_SERVICE - RETURN_REPLENISHMENT_INVOICE - CUSTOMER_RETURN_INVOICE - CUSTOMER_RETURN_REPLENISHMENT_INVOICE - REPLENISHMENT_POSITIVE_ADJUSTMENT_INVOICE - RETURN_REFUSAL_INVOICE - RETURN_REFUSAL_PARTIAL_INVOICE - VALUE_REDUCTION_INVOICE - EVENT_112130 - EVENT_112150 - EVENT_110111 - EVENT_110110 example: SALE_INVOICE operation_type: type: string enum: - SAIDA - ENTRADA description: >- `SAIDA` for outgoing (goods leaving the warehouse), `ENTRADA` for incoming. example: SAIDA operation_nature: type: string description: >- Nature of the operation as printed on the NF-e (natureza da operacao). example: Venda de mercadoria example: invoice_type: WEBMANIA invoices: - key: '00000000000000000000000000000000000000000000' identifier: SALE987654 purpose: SALE_INVOICE operation_type: SAIDA operation_nature: Venda de mercadoria responses: '200': description: >- Invoices registered. `new_invoice_ids` holds the IDs of the invoices created; when every key already existed, it is empty and `update_invoice_ids` lists the keys that were refreshed instead. content: application/json: schema: type: object required: - new_invoice_ids properties: new_invoice_ids: type: array items: type: integer description: IDs of the invoices created by this request. example: - 7801 update_invoice_ids: type: string description: >- Comma-separated access keys of invoices that already existed and were refreshed. Only present when nothing new was created. example: '00000000000000000000000000000000000000000000' examples: created: value: new_invoice_ids: - 7801 alreadyExisted: value: new_invoice_ids: [] update_invoice_ids: '00000000000000000000000000000000000000000000' '401': $ref: '#/components/responses/Unauthorized' '422': description: Validation or business error content: application/json: schema: $ref: '#/components/schemas/Error' examples: missingInvoices: value: error: Parameter invoices is required badKey: value: error: Parameter key must contain numbers only invalidPurpose: value: error: >- Parameter purpose must be within ["SYMBOLIC_RETURN_INVOICE", "SALE_INVOICE", ...] unsupportedType: value: error: only WEBMANIA is supported for now invalidStatus: value: error: 'order id 987654 is not in a valid status: shipped' duplicateIdentifiers: value: error: 'duplicate invoice identifiers provided: ["SALE987654"]' duplicateKeys: value: error: >- duplicate invoice keys provided: ["00000000000000000000000000000000000000000000"] identifierExists: value: error: 'some identifiers provided already exist: ["SALE987654"]' orderNotFound: value: error: Couldn't find Order with 'id'=0 fiscalProviderError: value: error: 'WebmaniaError: ' '500': $ref: '#/components/responses/InternalServerError' security: - bearerAuth: [] components: responses: Unauthorized: description: >- Missing or invalid token, wrong credentials, or no access to the requested store. content: application/json: schema: $ref: '#/components/schemas/Error' examples: invalidToken: value: error: Unauthorized message: invalid token noHeader: value: error: Unauthorized message: no authorization header found storeNotAllowed: value: error: Unauthorized message: not allowed to show? this Store InternalServerError: description: >- Unexpected error. Retry with backoff; if it persists, send the timestamp to Cubbo support. content: application/json: schema: $ref: '#/components/schemas/Error' example: error: 'unexpected error, timestamp: 1760000000' schemas: Error: type: object description: Error body returned by every failed request. required: - error properties: error: type: string description: >- Human-readable description of the failure. For `401` responses it is always `Unauthorized`. example: Parameter store_id is required message: type: string description: >- Present on `401` responses only; the reason the request was rejected. example: invalid token code: type: - string - 'null' description: >- Stable machine-readable code, present on some order, return and replenishment errors. example: ORDER_ALREADY_EXISTS context: type: - object - 'null' description: >- Extra data about the failure when available, for example the id of the conflicting order. additionalProperties: true example: order_id: 987654 securitySchemes: bearerAuth: type: http scheme: bearer bearerFormat: JWT description: >- Token returned by `POST /auth/token`, sent as `Authorization: Bearer `. ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.