Finero has a public, tenant-scoped REST API. The endpoints, fields and examples live in a reference generated from the API itself, and this page does not reproduce them: a second copy is a second thing that can go stale, and the stale copy always wins an argument it should lose.
What this page covers is everything the generated reference cannot tell you. What the API is for, which of the two access models to choose, how to get a credential, and what does not exist yet.
Canonical location
getfinero.com/api-docs redirects to app.getfinero.com/api-docs
Generated from the API. Endpoints, schemas, field-by-field descriptions and worked examples.
What the API is for
Finero sits between your ERP and your payment provider and runs the collections cycle. The API exposes the state it maintains while doing that:
- Receivables state. Invoices and their ageing, as Finero currently understands them after syncing from your ERP.
- Payments and application. What was collected and how it was applied back against invoices.
- Payment links. Hosted links raised against a specific installment. Listing and reading them is ordinary read access; creating one and deactivating one are writes and need an admin key. The amount is not supplied by the caller: it is bounded by what is actually outstanding on that installment.
- Integration health. The state of ERP and payment-provider connections, and the ability to trigger a sync rather than wait for the schedule.
What it is not: a general ledger, or a replacement for your ERP. Your ERP stays the record of truth for the invoices themselves. Finero holds the collections state around them. Getting that boundary right early saves rebuilding an integration that treated Finero as a system of record.
Two ways in, and they are not interchangeable
The API key model and the MCP model authenticate different subjects. This is the first decision to make, and the wrong choice is expensive to unwind:
- API key. Acts as the workspace. The full HTTP surface. Right for backend services, sync jobs and anything unattended. See authentication.
- MCP session. Acts as the person who approved it. Read-mostly and narrower. Right for an assistant working on someone's behalf. See the MCP server.
If you hold an API key, use the HTTP API. Routing a backend service through an assistant-shaped session adds a consent step with nobody present to consent.
Starting an integration
Generate a client from the OpenAPI specification rather than hand-writing one, and regenerate in CI so an API change becomes a failed build instead of a production incident. Create a key under Settings then API in the application, and keep it server-side.
Begin with read-only calls. There is no sandbox environment and no CLI, so your first request runs against a real workspace. Pick one whose data you can afford to read while you are still finding your way around.
Which source wins
The generated reference, always. It is produced from the deployed API, so it describes what is actually running. This marketing site describes the product and can lag a release. If the two disagree, trust the reference and tell us, because the disagreement is a bug on this side. For agents, the API llms.txt is the orientation document written for machine readers, and /.well-known/api-catalog is the RFC 9727 index of every surface.