Email debit note
Queues an email with the RIDE and the authorized XML. In every environment the document is already sent on its own when it is authorized, to its recipient; this send is for resending it, to its recipient or to the addresses you give.
Your API key, which acts for the one business it was created for: fb_sandbox_… issues in sandbox, fb_test_… in test, the tax authority's testing service, and fb_live_… in live.
In: header
Path Parameters
uuidRequest Body
application/json
TypeScript Definitions
Use the request body type in TypeScript.
Who to send it to. If you omit it, it goes to the document's recipient, in any environment.
1 <= items <= 10Response Body
application/json
application/problem+json
application/problem+json
application/problem+json
application/problem+json
application/problem+json
application/problem+json
curl -X POST "https://example.com/v1/ec/debit-notes/497f6eca-6276-4993-bfeb-53cbbbba6f08/email" \ -H "Content-Type: application/json" \ -d '{}'{ "object": "email", "document_id": "b792e8ae-2cb4-4209-85b9-32be4c2fcdd6", "to": [ "string" ]}Renumber debit note POST
Only for a `returned` document with error 45, SECUENCIAL REGISTRADO: another document of the RUC already has that number at the SRI. It takes the next number in its series with a new access key, keeps its content and its issue date, gains a revision and goes back to `pending`. In `sandbox` and `test` this happens on its own; in `live` never, because that number belongs to an authorized document that Fiscalbase does not know about.
The journey of the document GET
Every step it went through, from newest to oldest: accepted, signed, received, authorized or returned, the RIDE generated, each email sent and each correction.