REST API

Create invoices from your code, your agents, or anywhere

Bearer-token auth. JSON in, JSON out. OpenAPI 3.1 spec. MCP-ready. The same JSON shape your agent would return is the same shape the API expects, so AI flows and human flows share one schema.

Swagger UI → Raw OpenAPI spec

The JupiterInvoice API exposes invoices and customers as a clean REST surface so any client (a script, a SaaS integration, an LLM agent, an MCP-enabled assistant) can create and manage invoices on behalf of a sender. Every monetary value is integer cents, every date is ISO, and every endpoint returns the same JSON shape its UI uses internally. There is no second schema to learn.

Quick start

1

Mint an API key

From the Integrations page. Each key starts with jk_live_ and is shown exactly once.
2

Send a JSON request

Pass the key as a Bearer token. Body matches the OpenAPI Invoice schema.
3

Get back a share URL

The response includes a share_url you can paste into an email, a Slack DM, or anywhere else. The recipient opens it and can interact with the invoice immediately.

Create an invoice

Minimum payload: a recipient (company or email), at least one line item, a due date.

curl -X POST https://jupiterinvoice.com/api/v1/invoices \
  -H "Authorization: Bearer jk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "currency": "USD",
    "due_date": "2026-06-01",
    "recipient": {
      "company": "Acme Corp",
      "email": "ap@acme.com"
    },
    "line_items": [
      {
        "description": "Brand identity system",
        "quantity": 1,
        "unit_price_cents": 250000
      }
    ]
  }'

Returns 201 with the full invoice including share_url and the per-customer Stripe-style invoice number (e.g. ACME-0001).

List your invoices

curl https://jupiterinvoice.com/api/v1/invoices \
  -H "Authorization: Bearer jk_live_..."

Cursor-paginated; pass cursor from the previous response's next_cursor.

Available endpoints

POST /api/v1/invoices Create an invoice

GET /api/v1/invoices List invoices, cursor-paginated

GET /api/v1/invoices/{number} Fetch one invoice

PATCH /api/v1/invoices/{number} Partial update; locked invoices reject with 409

POST /api/v1/customers Create a customer

GET /api/v1/customers List customers

GET /api/v1/customers/{id} Fetch one customer

Conventions

•Money is integer cents. Never floats. unit_price_cents: 250000 = $2,500.00. Same for subtotal_cents, total_cents, etc.
•Quantities are JSON numbers. "quantity": 1.5 for one and a half hours; "quantity": 1 for a fixed-fee line.
•Tax rate is a percentage. "rate": 20.0 for 20%. Up to 2 decimals (e.g. 8.875).
•Dates are ISO. "due_date": "2026-06-01".
•Timestamps are UTC ISO 8601. "sent_at": "2026-05-01T12:00:00Z".
•Auth is Bearer. Authorization: Bearer jk_live_.... No cookies, no CSRF.
•Errors are JSON. {"error": "...", "field": "..."}. Status codes follow REST norms (400 / 401 / 404 / 409 / 422).

For agents: the MCP server

JupiterInvoice runs an MCP (Model Context Protocol) server at /mcp. Connect Claude Desktop, Cursor, Continue, or any MCP-capable client and it gets seven tools that mirror the REST API: create / list / get / update invoices and create / list / get customers.

Auth is the same Bearer token you'd use for the REST API. Mint one from the profile page, then drop this into your client's MCP servers config:

{
  "mcpServers": {
    "jupiterinvoice": {
      "type": "http",
      "url": "https://jupiterinvoice.com/mcp",
      "headers": {
        "Authorization": "Bearer jk_live_..."
      }
    }
  }
}

Streamable HTTP transport (MCP spec 2025-06-18). No stdio, no install, no Node. Once configured, your agent can ask things like "create an invoice for $2,500 in design work for Acme Corp due in 30 days" and the model picks the right tool with the right shape.

For your own LLM pipeline

If you're building an agent that doesn't speak MCP, just return JSON matching the Invoice schema from your model (Claude / GPT / etc.) and POST it directly to /api/v1/invoices. No translation layer needed; the API and MCP tools accept the exact same shape.

The OpenAPI 3.1 spec at /api/openapi.json (also at /.well-known/openapi.json) is the canonical contract for both surfaces.