Skip to content
Finero
Developers

Finero API documentation

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.

Frequently asked

Does Finero have a public API?

Yes. Finero has a public, tenant-scoped REST API for external systems and AI agents, documented in a generated reference at app.getfinero.com/api-docs and described by an OpenAPI specification. Both are reachable from short paths on getfinero.com: /api-docs and /openapi.json.

Where is the Finero API documentation?

getfinero.com/api-docs redirects to the generated reference. It is generated from the API itself, which is why it is the authoritative source rather than anything written on this marketing site. This page is orientation: what the API is for and which access model to choose.

What can the Finero API do?

It exposes the receivables state Finero maintains: invoices and their ageing, payments and how they were applied, payment links raised against an installment, the status of ERP and payment-provider integrations, and the ability to trigger a sync. Creating and deactivating a payment link are writes and need an admin key; everything else listed here is read access, and a link's amount is bounded by what is outstanding on the installment rather than supplied by the caller. It is not a general ledger and not a replacement for your ERP, which remains the record of truth for invoices themselves.

How do I get access to the Finero API?

Create an API key in the application under Settings then API. It is self-serve, shown once on creation, and revocable from the same screen. No sales conversation is required to start building.

Is there a sandbox or a CLI?

No to both. You build against the specification and run against a real workspace, so begin with read-only calls on a workspace whose data you can afford to read. We state this rather than let it be discovered midway through an integration.

Which is authoritative if this site and the API reference disagree?

The API reference, always. It is generated from the API, so it describes what is actually deployed. This site describes the product and can lag a release. If you find a contradiction, trust the reference and tell us, because the contradiction is a bug on this side.

Building on Finero? Let's talk through the integration.

Tell us what you are connecting and we'll point you at the right entry point, or get you a key.