REST API for Accounting Data

Because every REDA Financials document is a Salesforce custom object, the standard REST API is your integration front door: create invoices from your CRM or billing system, query balances into a data warehouse, post documents from middleware — all with the endpoints your team already knows.

The canonical pattern: create draft, then post

The endpoints, at a glance

Nothing here is REDA-specific — these are the standard Salesforce REST endpoints, shown against the refin__ objects (the package is built at API v65.0; any current version works):

Posting a draft, on the wire

The posting call is deliberately anticlimactic — one field:

PATCH /services/data/v65.0/sobjects/refin__Sales_Invoice__c/a0X8d000001AbCdEAV

{
  "refin__Status__c": "Posted"
}

Success is an HTTP 204 No Content — and a fully posted document behind it. A refusal comes back as the standard error array carrying the package's human-readable message; for example, an integration user without a REDA licence seat sees:

[
  {
    "message": "You must be a licensed REDA Financials user to create, edit, or delete Accounting Transactions. Contact your administrator.",
    "errorCode": "FIELD_CUSTOM_VALIDATION_EXCEPTION",
    "fields": []
  }
]

Reading back what you created is plain SOQL:

GET /services/data/v65.0/query
    ?q=SELECT Id, Name, refin__Status__c
       FROM refin__Sales_Invoice__c
       WHERE refin__Status__c = 'Draft'

For the insert bodies themselves, pull the field list from the describe endpoint or Object Manager rather than this article — your org's field sets and required fields are the truth, and the extra dimension fields your admin added are part of it.

What the platform fills in for you

Reading data

• SOQL through the query endpoint — open invoices, unapplied receipts, aging fields (they're formula fields on the records), whatever your dashboard needs.
• The ledger itself — refin__Accounting_Transaction__c is the posting truth; sum debits and credits by GL account and you've rebuilt any balance externally.
• Rollups are fields — an invoice's balance due, a receipt's unapplied amount, a budget line's committed figure: all queryable directly, no computation on your side.

Rules of the road

• No bypass exists: posted documents are locked to API edits exactly as to users; corrections go through unpost/void flows, programmatically the same status transitions.
• Applications are records too — creating a refin__Cash_Receipt_Application__c applies a receipt (all the matching guards run); deleting it un-applies.
• Respect the closure dates — writes into closed books are refused; your integration should date documents in open periods like any accountant.
• Idempotency is on you — the natural key is your source system's reference (put it in the Reference field and check before insert; the vendor-reference duplicate validation helps on the AP side).

Common mistakes to avoid

Where to go next

1. Bulk API — the same pattern at migration scale.
2. API Overview — the whole landscape.
3. Opening Balances & Data Migration — the classic REST/Bulk project.

Frequently asked questions