Billing documents
Work with supported invoice, estimate and recurring-invoice operations without turning the integration into a second billing authority.
Developer API
Connect billing records without blurring system ownership.
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
- api.invoicera.com/xml/1.1/
- Transport
- HTTPS
- Format
- XML request and response
- Access
- Account API token
Confirm operation coverage, account access and applicable limits before production sizing.
In brief
The Invoicera API is an integration surface for supported billing records. 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.
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.
The outline below shows the verified transport, endpoint, token requirement and XML format. The precise operation and XML body depend on the record and method being implemented.
POST https://api.invoicera.com/xml/1.1/
Authorization: [account API token]
Content-Type: application/xml
<request>
<!-- supported operation and fields -->
</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.
Source-backed method index
Review the recovered XML v1.1 operations and request structure.
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?
Requests require an account API token. Treat the token as a secret, keep it out of browser code, analytics, logs and source repositories, and confirm the current account-access process before implementation. Store it in an appropriate server-side secret manager and restrict who can retrieve it. Test the unauthorised response deliberately. Rotate or revoke access if the integration owner, deployment environment or security boundary changes.
Which records can an integration work with?
The established API surface groups operations around billing documents, customers and staff, products and services, expenses, projects, tasks and time entries. That grouping helps teams identify a plausible integration path, but it is not a promise that every create, read, update or delete method is enabled for every account. Confirm the exact operation, required fields, response and account availability 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.