Use the Relayer API to submit an SDK-prepared transaction package for execution on Stellar. Submission is asynchronous: acceptance creates a relay request, not a confirmed blockchain transaction. Use the service base URL supplied for your environment. The routes below belong to the Privacy Layer Transfer API, not the Compliance Platform Service API.

​
Methods

​
Submit a transaction package

Send JSON with Content-Type: application/json. Build the package from the prepared SDK operation rather than constructing proof data manually. The SDK and the environment’s circuit configuration determine which conditional fields to include. Proof-related material can be sensitive: do not log the full request body. The response contains: Submitting the same canonical payload with the same pool and nullifier identity reuses the existing request. A different payload for that identity returns 409 conflicting_payload. Admission limits still apply to repeated submissions.

​
Track the result

Call GET /api/relay-requests/{relayRequestId}. No request body is needed. The response includes relayRequestId, status, createdAt, updatedAt, and retryAllowed. It can also include attemptNumber, transactionHash, and publicReason. Persist the request ID so you can resume status checks after a reload or service restart. A transaction hash alone does not indicate success.

​
Retry a request

When retryAllowed is true, call POST /api/relay-requests/{relayRequestId}/attempts with no body. The response has the same shape as the status response. Eligibility is checked again when the request arrives. Do not start a replacement transaction while the existing request is submitted or reconciling. Continue checking its outcome.

​
Errors

Admission errors use a JSON reason field. After acceptance, operation failures appear in status and publicReason. Reasons include invalid_proof, kyt_rejected, nullifiers_spent, simulation_failed, and transaction_failed. See KYT API for screening decisions and SDK and APIs for the integration model.