Live Reconciliation via API
PRODUCTION API END POINTS:
Single survey:
POST: https://api.spectrumsurveys.com/buyers/v2/adjustments/surveys/{surveyId}?operationType=LIVE_RECONCILIATION&reconStatus={1/2}
Multiple Survey:
POST: https://api.spectrumsurveys.com/buyers/v2/adjustments?operationType=LIVE_RECONCILIATION&reconStatus={1/2}
Change the transaction status to Complete
use
reconStatus = 1
Change the transaction status to Buyer_Reconciliation_Reject
use
reconStatus = 2
In live reconciliation mode, it is possible to enter the reason for the reconciliation made in an additional field. Please note this is optional.
If included, the reason value should be added in
"change_reason"
and these are the options:Suspected Fraud
Respondent Quality (speeding, straightlining, text response...)
Ghost Completes
Client Rejected
Duplicate Respondent
Any other variation is accepted and is recorded as
Respondent Quality
.
Example Single Survey Call:
API:
Change to Complete
POST:
{url}/adjustments/surveys/:surveyId?operationType=LIVE_RECONCILIATION&reconStatus=1
Change to Buyer_Reconciliation_Reject
POST:
{url}/adjustments/surveys/:surveyId?operationType=LIVE_RECONCILIATION&reconStatus=2
REQUEST PAYLOAD:
[
{
"transaction_id": "7lNK5AGrSL3bk5tV4gw0Tr",
"change_reason": "Suspected Fraud" // optional
},
{
"transaction_id": "7dTdSUUWkR9DBs7rUi5jdT"
},
{
"transaction_id": "5EmEbeX9mEblEpwP6yHG1K"
},
{
"transaction_id": "6HkYQWFMcIcDOTxfnIi6op"
}
]
RESPONSE PAYLOAD:
CODE: 200 OK
NOTE: If one or more transaction_id/s
(TXs) passed are ineligible or already reconciled, the system will start the reconciliation process and those TXs will be skipped.
Response explanation:
"eligible"
: are the transactions that are eligible and the status changed within the process
"rejected"
: are the transactions that changed from Complete
to Buyer_Reconciliation_Reject
"completed
”: are the transactions that changed from Buyer_*
to Complete
"test"
: are the transactions captured via the button test (available in UI)
"transactions"
: total completes uploaded
"transactionsWithDesiredStatus"
: are the transactions that already have the status requested with this reconciliation process.
NOTE: to get the transactions not eligible to reconcile or not reconciled withing the recon process you can use this formula
transactions - eligible = not eligible / not reconciled
Errors Codes:
All transactions are invalid or belong to another survey
The reconciliation process will not start
Some, but not all, transactions are invalid or belong to another survey
The reconciliation process will not start
All transactions are ineligible for reconciliation
The reconciliation process will not start
The total TX rejects allowed is reached. The limit set at the moment is 50%
The reconciliation process will not start
DESCRIPTION:
STAGING API and Payload:
1 - Reconciliation Single Survey:
Buyer API endPoint - Change the transaction to Buyer_Reconciliation_Reject
:
Request Payload:
Response:
2 - Reconciliation multiple surveys (Bulk Reconciliation)
Buyer API endPoint - Change the transaction to Buyer_Reconciliation_Reject
:
Request Payload:
Response:
These are the label show:
Reject : Reconciliation via UI - TX changes to
buyer_rejects
Reject (API): Reconciliation via API - TX changes to
buyer_rejects
Complete: Reconciliation via UI - TX changes to
complete
Complete (API): Reconciliation via UI - TX changes to
buyer_rejects
Accept: Reconciliation via UI - Any TX in the file will changes to
complete
if they are eligible, and the TX current completes not in the file, will changebuyer_rejects
Accept (API): Reconciliation via API - Any TX in the file will changes to
complete
if they are eligible, and the TX current completes not in the file, will changebuyer_rejects