Skip to main content
Retempo returns JSON error objects with an error field on every non-successful response. The error value is a human-readable string that describes what went wrong. Use the HTTP status code to quickly classify the problem, then read the error message to understand the specific cause.
Use this reference to identify the root cause and apply the correct fix before retrying your request.

HTTP Status Codes

400 Bad Request

A 400 response means your request contained invalid input, was missing a required field, or violated a constraint. The error message will identify the specific field or rule that failed. Correct the request body and retry.

404 Not Found

A 404 response means Retempo could not find the resource you referenced. This usually means the ID is incorrect, the resource belongs to a different service, or it has not been created yet.

409 Conflict

A 409 response means a record with the same unique key already exists. Retempo enforces uniqueness on certain field combinations to prevent duplicate entries.
If you receive a 409 on a settlement submission, the settlement may have already been recorded on-chain. Check your settlements list before resubmitting to avoid duplicating a payment.

500 Internal Server Error

A 500 response indicates an unexpected server-side error or a failure during on-chain submission to Arc. These errors are not caused by your request format, but you may be able to retry after investigating the underlying issue.
A 500 error from the settlement endpoint sets the settlement status to FAILED. Retempo does not automatically retry failed settlements. You must investigate and submit a new settlement record to reattempt payment.

Arc Contract Errors

When Retempo submits a settlement to Arc, the Arc smart contract validates the transaction before recording it on-chain. Contract-level validation failures surface as 400 or 500 errors from the Retempo API. Use this reference to interpret the underlying cause.

Troubleshooting

A FAILED settlement means the on-chain submission to Arc did not complete successfully. Take the following steps to diagnose and resolve it:
  1. Check the Arc explorer. Use the transactionHash returned with the settlement to look up the transaction on the Arc block explorer. The contract revert reason will tell you exactly which validation rule failed.
  2. Verify your addresses. Confirm that both payerAddress and merchantAddress are valid, non-zero EVM addresses. A zero address will cause an InvalidAddress rejection.
  3. Verify the amount. Ensure the settlement amount is greater than zero.
  4. Check for duplicates. If the Arc error is SettlementAlreadyRecorded, the settlement already exists on-chain. Fetch the invoice to confirm it is marked PAID — if it is, no further action is needed.
  5. Resubmit. Once you have identified and corrected the issue, create a new settlement record and submit it. Failed settlements cannot be reactivated.
A 404 on an invoice request means Retempo could not locate the invoice you referenced. Check the following:
  • Verify the invoiceId. Retempo IDs are cuid strings (e.g., clz1abc2def3...). Confirm you are using the correct ID and have not truncated or modified it.
  • Check the service scope. Invoices are scoped to a service. If you are querying invoices for a specific service, ensure the invoice belongs to that service and not a different one.
  • Confirm the invoice exists. Fetch the full list of invoices for your subscription to see all available invoice IDs.
A 409 means a record with the same unique key already exists in Retempo. Rather than creating a duplicate, fetch the existing record:
  • For settlements: Query your settlements list filtered by invoiceId to retrieve the existing settlement. Check its status before deciding whether to take further action.
  • For other resources: Use the list or get endpoint for that resource type to retrieve the existing record by its unique fields.
If you genuinely need a separate record (for example, a corrected settlement after a failed one), ensure the new record uses a different referenceHash or unique identifier as appropriate.