Skip to main content
The Saasybill API lets your software do what your team does in the app. A signup on your platform creates a subscription. A seat change on your platform updates its units. Saasybill raises the invoice in Xero each time.
This is the developer reference. To do the same work by hand, see the Guides tab. To understand how plans, subscriptions and invoices fit together, start with How Saasybill works.

Base URL

Every request goes to the same host as the app, under /api/v1.
Requests and responses are JSON. Send Content-Type: application/json on every request with a body.

Your first request

Send your API key as a bearer token. This request returns the organisation the key belongs to, so it doubles as a connectivity check.
Response
Don’t have a key yet? Create one in Developer Settings.

What you can do

Plans, charges and customers are managed in the app and synced from Xero. The API reads them so your platform can sell against them. Subscriptions are the object your platform writes.
Not available yet: add-ons, catalogue writes (plans, charges, categories), credit notes, invoice writes, managing keys or webhook endpoints through the API, a sandbox, OAuth, and SDKs.

How an integration fits together

1

Read your catalogue

List plans and charges once and cache the ids and codes. Plans change rarely.
2

Create subscriptions on signup

Send POST /v1/subscriptions with an Idempotency-Key. Saasybill creates the subscription and its first invoice, and sends the invoice to Xero.
3

Keep units in sync

When seats or usage change on your platform, send the new total with POST /v1/subscriptions/{id}/units. Saasybill decides whether to invoice now, defer to renewal, or credit.
4

Listen for changes

Subscribe to webhooks to hear when invoices are raised or paid, instead of polling.

Explore

Quickstart

Create a key and your first subscription in minutes.

Authentication

API keys, scopes and how to keep them safe.

Webhooks

Get told when customers, subscriptions and invoices change.

Errors

Every error code and how to handle it.

OpenAPI document

The full API is described as an OpenAPI 3.1 document. Import it into Postman or Insomnia, or use it to generate a client in your language.
The document is public. It describes the interface, not anyone’s data, so you can read it before you have a key.