How responses are structured
The API returns errors in two general shapes: Validation errors (400) — a top-levelerrors object keyed by field name:
message string, either at the top level or nested under data:
data object or array containing the resource, or a confirmation message for actions like void, refund, and delete.
Message placement is inconsistent across endpoints — sometimes
message, sometimes data.message. Error wording also varies slightly between endpoints. The tables below reflect the API exactly as documented.Common messages
These appear across multiple endpoints.Merchant Management
List Merchants GET /api/merchant/list
Show Merchant GET /api/merchant/show
Create Merchant POST /api/merchant/create
Update Merchant PATCH /api/merchant/update
Get Signup Form Link GET /api/merchant/get-form-link
Transaction Management
List Transactions GET /api/transactions
Charge a Credit Card POST /api/transaction/charge-card
status_code and status_text are passed through from the processor. 00 / APPROVAL and 05 / DECLINE are the most common but other processor codes are possible.Charge a Bank Account (ACH) POST /api/transaction/charge-ach
Tokenize a Credit Card POST /api/transaction/tokenize-card
Show Transaction GET /api/transaction
Refund Transaction POST /api/transaction/refund
Void Transaction PATCH /api/transaction/void
Addresses
List / Show / Create / Update / Delete GET /api/address/*
Customer Management
List / Show / Create / Update / Delete GET|POST|PATCH /api/customer/*
Deleting a customer also cancels any recurring payments associated with that customer.
Deposit Management
List Deposits GET /api/deposit/list
List with Transactions / Show Deposit GET /api/deposit/list-with-trans GET /api/deposit/show
Payment Method Management
List / Show / Create / Update / Delete GET|POST|PATCH /api/payment-method/*
To delete a payment method that has active recurring payments, cancel or reassign those recurring payments first.
Recurring Payments
All Recurring Payment endpoints GET|POST|PATCH /api/recurring-payment/*
Notable fields in success responses:
last_run_status (Success or Failed), last_run_failed_count, and error — a processor-provided reason such as EXPIRED CARD when the last attempt failed.
Pause defaults paused_until_date to 2099-12-31 if no date is provided.
Zapier Endpoints
For the transactions by phone endpoint, the request body must use either
last_days or start_date + end_date — not both.

