Billing documents
Work with supported invoice, estimate and recurring-invoice operations without turning the integration into a second billing authority.
Developer API
An invoicing API that keeps system ownership clear.
Use Invoicera's token-authenticated XML service to build a controlled connection around supported billing records. Keep the source, review state, downstream owner and exception path explicit.
Connection contractCurrent
- Endpoint
- https://api.invoicera.com/xml/1.1/
- Transport
- HTTPS
- Format
- XML request and response
- Access
- Account API token (My Account, Invoicera API tab)
- First call
- getAccountInfo
Confirm account access and plan allowances before production sizing.
In brief
The Invoicera API is a token-authenticated XML integration surface for supported billing records, such as invoices, estimates, recurring invoices, clients, products, expenses, projects and time logs. It is most useful when the implementation defines which system owns each record, preserves commercial fields and handles rejected or repeated requests deliberately.
Supported record areas
Start with the record, not the endpoint.
An API connection should solve a defined hand-off. Choose the records that need to move, name their authority and leave unrelated systems alone. They are the same invoices, estimates and recurring invoices your team runs through Invoicera invoicing and Invoicera billing, so the integration should carry them, not redefine them.
Customers and catalogue records
Connect supported client, staff, product and service records while retaining the identifiers that keep both systems aligned.
Operating inputs
Use supported expense, project, task and time-entry operations where those records genuinely belong in the billing flow.
Implementation path
Build one controlled hand-off at a time.
The first production milestone should be a complete, observable path for one record type, including the failure case.
- 01
Name the owner of each record
Decide whether Invoicera, the source application or the downstream system owns creation and correction. One record should not have two competing authorities.
- 02
Authenticate and test a narrow path
Use the account API token over HTTPS and begin with a non-sensitive test record. Confirm the operation, response and permissions before widening the integration.
- 03
Map identity and commercial fields
Retain customer identifiers, dates, currencies, amounts, tax treatment and document status. A successful request is not useful when the resulting record is commercially ambiguous.
- 04
Design the exception path
Record failures, retries and rejected records. Make it clear who resolves a problem and how the integration proves that a document was created once, not twice.
Connection outline
Keep credentials and commercial decisions outside the request template.
Every call is one HTTPS POST with the token as the HTTP Basic username and one XML document in the xml_request form field. The first call to try is getAccountInfo: it takes no fields and returns your company name, country and currency, so it proves the token works without touching billing records.
POST https://api.invoicera.com/xml/1.1/
Authorization: Basic [API_TOKEN_AS_USERNAME:X]
Content-Type: application/x-www-form-urlencoded
xml_request=<?xml version="1.0" encoding="utf-8"?>
<request method="getAccountInfo">
</request>Worked example
Send an approved billing record downstream without creating a second authority.
- Source record
- Approved invoice in Invoicera
- Integration action
- Send the supported document fields
- Downstream owner
- The receiving operation defined by the team
- Exception control
- Record failure, retry and final external identifier
Production checklist
Confirm the boundary before writing the connector.
A durable integration plan covers commercial access, technical behaviour and operational ownership together.
- 01
Access and operation coverage Confirm that the account and required methods are available.
- 02
Secrets and environments Keep tokens server-side and separate test activity from live records.
- 03
Identity and mapping Preserve customer, document and downstream identifiers.
- 04
Limits and scheduling Size imports and retries against the limits confirmed for the account.
- 05
Errors and duplicates Define retry rules, escalation and duplicate prevention.
- 06
Reconciliation Prove the final state rather than assuming a successful response completed the business process.
Complete method reference
Review all 78 methods with field tables, examples and errors.
Developer questions
Plan against the current interface.
Confirm anything account-specific before committing an implementation estimate.
Is the current Invoicera API REST or XML?
The currently verified public endpoint is an XML service at api.invoicera.com/xml/1.1/. It responds with XML and requires an API token. Plan request construction, response parsing and error handling around XML. Do not scope a JSON or REST implementation merely from the API label. If a different interface is essential, ask the Invoicera team to confirm whether one is current and available for your account before estimating the connector.
How does API authentication work?
Each request sends the account API token as the HTTP Basic username; only the token is checked. The account owner finds the token in Invoicera under My Account, on the Invoicera API tab, and changing the account password resets it. Treat the token as a secret: keep it out of browser code, analytics, logs and source repositories, store it in a server-side secret manager and restrict who can retrieve it. Test the unauthorised response deliberately.
Which records can an integration work with?
The reference documents 78 XML methods in 11 groups: invoices, estimates, recurring invoices, clients, staff, products and services, expenses, projects, tasks, time logs and supporting operations such as offline payments. Each method lists its request fields with required flags and accepted values, a full request and response example and its error messages. Confirm account access and plan allowances for the record flow you intend to build.
Does Invoicera publish one fixed API request limit?
This page does not publish a universal request limit because limits and commercial access can change by account or implementation. Confirm the applicable limit before sizing imports, retries or scheduled synchronisation. The design should still use bounded batches, backoff and observable queues instead of sending an uncontrolled burst. Capacity planning must include normal volume, recovery after downtime and the additional calls created by validation or reconciliation.
What should be tested before production use?
Test authentication failure, validation errors, duplicate prevention, retries, currency and date handling, customer matching, document status and reconciliation. Include a timeout, a repeated request and a record rejected for a missing required field. Use representative but non-sensitive data, then retain request and response evidence appropriate to your security policy. Production approval should name the monitoring owner, exception owner and rollback or pause procedure.