An internal order tool can prepare a Pepper invoice draft for staff to review. MCP and HTTP tools support permitted reads, exact previews, draft creation and draft updates. This guide covers an integration that stops at the draft. Issuance is a separate prepared request that requires the delegated person's approval; sending is unavailable to clients.
Build the integration around that stopping point. A successful draft response means a draft exists. It does not mean the client received an invoice or that the business received payment.
Request the smallest useful grant
The owner enables access and creates an expiring connection. Calls remain within the granted capabilities and the delegated user's current record permissions. A credential cannot add a permission the user lacks.
Send the bearer credential from a server or command-line client over HTTPS. Keep it out of browser code, URLs and logs. Requests with an Origin header fail. MCP clients can also use browser OAuth sign-in. The connection manual explains both connection methods.
Connections expire after 1 to 30 days. The body limit is 256 KiB, invoices accept 1 to 100 lines, and lists return at most 50 records per page. Both the connection and IP address have a 60-request-per-minute limit. Clients behind one IP share its allowance.
Preview the exact input
Use a permitted customer ID, currency, dates and complete line set. Monetary values use strings of minor units. In EUR, "12500" means EUR 125.00. A quantity of "2" makes EUR 250.00 before tax or discount. In JPY, the same price string means JPY 12,500.
Send that input to POST /api/v1/documents/preview. Let the server calculate the total. Do not calculate a floating-point total and ask Pepper to trust it. The client must also use an existing tax rate chosen for the transaction; the API cannot create one or decide the treatment.
Then send the same input to POST /api/v1/drafts with an Idempotency-Key. Open the returned document link for a human review of the customer, lines, dates and total.
Make retries preserve one operation
Keep the key and payload for an uncertain write. An identical retry returns the original result without creating a second draft. Reusing that key with another payload or target returns a conflict.
An update needs the draft's current lock_version and the full header and line set. A stale version changes nothing. Read the current record, compare it with the intended change and use a new operation key after review. A stored retry result describes the original write, so read again when you need the draft's present state.
Read the surrounding work
The optional MCP jobs also expose customers_context and invoices_receivables. Context includes only sections covered by both the connection grant and the person’s current permissions. Receivables keeps exact balances separate by currency and links to the same invoices as the screen. Neither tool writes a business record.
Use the job sequences and tool catalog for inputs, page limits and exclusions. Recorded reads are sampled in the audit log. Every new business operation must declare a tool or a reasoned exclusion; the real registry coverage check must pass.
Leave consequential actions with staff
Staff can issue through the application, or approve one client-prepared issue request. Approval applies only to the reviewed document and expires 10 minutes after preparation unless the owner sets another window. Only successful execution confirms issuance. Sending, recording a payment, exporting files and changing bank or tax settings also run only after a person approves each exact change; see Approve sensitive steps. A client never reaches a record that its person cannot open. No AI account is required; an ordinary integration can use the same HTTP calls.
Check the API request fields before implementing the integration; the reference also covers MCP tool names and prepared issuance requests. The client guide explains access and review. Use the changelog when choosing an integration target.