What the API will never do

The limits no key can cross, and the two calls that email your customer before they return.

What no key can do

These are not settings, and no access level opens them. They are properties of the surface.

• Write a ledger row any way but through the posting engine. Every write here runs the same operation the app's own buttons run, with the same balance check.
• Post into a closed period. A date inside one answers 409 period_locked, and there is no call that reopens a period.
• Change or delete anything already posted. Posted entries are immutable, enforced in the database itself. A correction is a reversing entry, made by a person in the app.
• Delete a customer or a vendor. There is no delete on this surface at all. No endpoint removes a record, and none archives one either.
• Reach another account. A key belongs to exactly one account, and every read and write it makes runs inside that account's boundary in the database.
• Post something the AI categorized without a person accepting it. POST /review-queue/{id}/accept is the only call on this surface that takes an item out of the review queue, and it is you, or your software acting as you, saying yes.
• Manage people or roles, change billing, connect a bank, create or revoke a key, or lock or unlock a month. There is no endpoint for any of them, and the identity a key acts under does not carry the permission either.

What it does that you might not expect

POST /invoices/{id}/send finalizes the invoice, posts it to the books, and emails your customer, all before the call returns. There is no API call that undoes it, and the email has already gone. Create the draft with POST /invoices first, read it back, and send it only when you are sure.

POST /invoices/{id}/remind emails your customer in the same way, in the request. A second reminder for the same invoice within 24 hours is refused with conflict, so software asked twice does not chase the same customer twice.

POST /expenses posts immediately. Nothing there is categorized by AI and nothing lands in the review queue: the account you send is the account it posts to. A vendorName that matches no existing vendor exactly creates a new vendor, and the match is case sensitive, so send vendorId when you have it.

POST /customers with a name that already exists returns the existing customer with created set to false and changes nothing else. It answers 200 rather than the 201 a real create answers, and created says the same thing in the body.

POST /invoices takes an optional currency. currency is the invoice's own currency, and defaults to US dollars when you leave it out. It is not taken from the customer, even when the customer is set to another currency, which is how the app's own invoice form behaves too.

GET /today refreshes when each signal was last seen, exactly as opening the Today page does. Nothing in your books changes, but it is not a read with no trace.

While a subscription is past due, every read keeps working, and any write that posts to the books answers read_only_billing_state. POST /customers, POST /invoices and POST /invoices/{id}/remind do not post, so those keep working. Each endpoint's page in the reference lists the codes it can answer.