Post Your First Journal in 5 Minutes

This is the shortest path from zero to a real double-entry entry in the ledger. You will create sandbox credentials, exchange them for a short-lived access token, post a journal, and read it back. If you only do one thing to evaluate Paprel, do this.

You need: a terminal with curl and jq, plus a Paprel sandbox workspace (self-serve, no sales call).


0. Create sandbox credentials (1 min)

Sign in at sandbox.paprel.com and create an App Connect client for your sandbox company. Grant it at least the journal list and journal add permissions. Copy these values while the client secret is visible:

  • Token URL — use the exact URL shown for the client
  • client_id
  • client_secret
  • Registered partner domain

Keep the secret server-side. Do not put it in browser code, a VITE_* variable, or a public repository.

1. Exchange credentials for a token (1 min)

Set the copied values, then use the OAuth 2.0 client credentials grant:

Shell
export APP_CONNECT_TOKEN_URL="https://api-sandbox.paprel.com/v1/app-connect/oauth/token"
export APP_CONNECT_CLIENT_ID="<your client_id>"
export APP_CONNECT_CLIENT_SECRET="<your client_secret>"
export PARTNER_DOMAIN="app.yourproduct.com"
export PAPREL_API_BASE="https://api-sandbox.paprel.com"
Shell
export ACCESS_TOKEN="$(curl --fail --silent --show-error \
  -X POST "$APP_CONNECT_TOKEN_URL" \
  -H "content-type: application/json" \
  -H "x-partner-domain: $PARTNER_DOMAIN" \
  --data "$(jq -n \
    --arg client_id "$APP_CONNECT_CLIENT_ID" \
    --arg client_secret "$APP_CONNECT_CLIENT_SECRET" \
    '{grant_type:"client_credentials", client_id:$client_id, client_secret:$client_secret}')" \
  | jq -r '.data.access_token // .access_token')"

Confirm that the exchange returned a token before continuing:

Shell
test -n "$ACCESS_TOKEN" && test "$ACCESS_TOKEN" != "null" && echo "Token ready"

The access token is short-lived and company-scoped. Cache it until shortly before expiry, then run the exchange again. Your client_secret is never sent on journal API calls.

2. Post a balanced journal (2 min)

A journal is a set of lines whose debits and credits must balance before it ever reaches the ledger. Here we record $100 of revenue — debit Cash (1010), credit Revenue (4000):

Shell
curl "$PAPREL_API_BASE/v1/accounting/journals" \
  -H "authorization: Bearer $ACCESS_TOKEN" \
  -H "x-partner-domain: $PARTNER_DOMAIN" \
  -H "content-type: application/json" \
  -d '{
    "currency": "USD",
    "date": "2026-06-27",
    "description": "First journal",
    "lines": [
      { "account_code": "1010", "debit":  "100.00" },
      { "account_code": "4000", "credit": "100.00" }
    ],
    "posted": true
  }'

You get back the created journal with an id, an identifier, and is_posted: true. If debits and credits don't balance, the API rejects it — the ledger never drifts.

3. Read it back (1 min)

Confirm the entry is in the ledger of record:

Shell
curl "$PAPREL_API_BASE/v1/accounting/journals" \
  -H "authorization: Bearer $ACCESS_TOKEN" \
  -H "x-partner-domain: $PARTNER_DOMAIN"

Your journal is there, immutable and auditable. That's the whole loop: product event → balanced journal → system of record you can report on.


What just happened

  • You posted a GAAP-grade double-entry entry over plain REST.
  • It was validated before it hit the ledger — unbalanced entries are rejected, not silently corrected.
  • It's now part of an append-only, exportable audit trail.

Next steps

  • Go deeper: Build Embedded Accounting in 20 Minutes — company, chart of accounts, invoicing, payments, and a live P&L.
  • Understand token handling: Authentication and tokens — credential storage, expiry, permissions, and request signing for non-App-Connect writes.
  • Browse the surface: the API reference documents all 260 operations.
  • Other credential paths: operator/API-credential writes require an x-data-signature; App Connect embed writes do not. Construction and test vectors are on authentication and tokens.
  • Ship faster: use the TypeScript SDK instead of raw curl (see the SDK README in the repo).
Evaluate Paprel

Build in sandbox, launch with a production trial

Use sandbox for developer testing with no billing. When you are ready for real workflows, start production on a monthly plan with a 14-day free trial.

API-First Delivery
Audit-Ready Controls
Sandbox And Guided Rollout
We use cookies to improve your experience.