PRODUCTION API END POINTS:
...
Change the transaction status to Buyer_Reconciliation_Reject
use
reconStatus = 2
In live reconciliation, is possible to add for each transaction an additional field that allow the user to add the reason for the the reconciliation. This part 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 has
Respondent Quality
.
Example Single Survey Call:
...
REQUEST PAYLOAD:
Code Block | ||
---|---|---|
| ||
[ { "transaction_id": "7lNK5AGrSL3bk5tV4gw0Tr", "change_reason": "Suspected Fraud" // optional }, { "transaction_id": "7dTdSUUWkR9DBs7rUi5jdT" }, { "transaction_id": "5EmEbeX9mEblEpwP6yHG1K" }, { "transaction_id": "6HkYQWFMcIcDOTxfnIi6op" } ] |
RESPONSE PAYLOAD:
Code Block | ||
---|---|---|
| ||
{ "adjustment_id": "b43ce6a3-9578-4ba6-8cc5-a4add094a352", "summary": { "desiredStatus": {21/33}, "transactionseligible": 42, "eligiblerejected": 40, "liveReconciledcompleted": 2, "test": 0, "completestransactions": 12, "rejectedtransactionsWithDesiredStatus": 0, "isApiUser": true } } |
Response explanation:
"eligible"
: are the transactions that are eligible and the status changed within the process
"liveReconciledrejected"
: are the transactions that are already live reconciled from the list"completes"
changed from Complete
to Buyer_Reconciliation_Reject
"completed
”: are the transactions that have already been completed from the listchanged from Buyer_*
to Complete
"rejectedtest"
: are the transactions that have already been rejected from the listcaptured 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 |
---|
NOTE: to get the transactions not eligible to reconcile or not reconciled withing the recon process you can use this formula
|
DESCRIPTION:
STAGING API and Payload:
...
Code Block | ||
---|---|---|
| ||
[ { "transaction_id": "7lNK5AGrSL3bk5tV4gw0Tr" "change_reason": "Respondent Quality" // optional }, { "transaction_id": "7dTdSUUWkR9DBs7rUi5jdT" }, { "transaction_id": "5EmEbeX9mEblEpwP6yHG1K" }, { "transaction_id": "6HkYQWFMcIcDOTxfnIi6op" } ] |
...
Code Block | ||
---|---|---|
| ||
{ "adjustment_id": "b43ce6a3-9578-4ba6-8cc5-a4add094a352", "summary": { "desiredStatus": 33, "eligible": 2, "rejected": 2, "transactionscompleted": 40, "eligibletest": 40, "liveReconciledtransactions": 2, "completestransactionsWithDesiredStatus": 10, "rejectedisApiUser": 0true } } |
2 - Reconciliation multiple surveys (Bulk Reconciliation)
...
Request Payload:
Code Block | ||
---|---|---|
| ||
[ { "transaction_id": "7by1JwD0oLzX1iip0liui4", "change_reason": "Suspected Fraud" // optional }, { "transaction_id": "7Er50MDCnV0b0bc91S8Qr1", "change_reason": "Respondent Quality" // optional }, { "transaction_id": "41JBHVbfHas8kzAwYhGW9l", "change_reason": "Ghost Completes" // optional }, { "transaction_id": "7mwVC728181yok8mKgDzQv", "change_reason": "Client Rejected" // optional }, { "transaction_id": "21NJOoeCB4mXoMZXg77bNo", "change_reason": "Duplicate Respondent" // optional }, { "transaction_id": "5j2UOEpgsMlXoLix0qtU0W" } ] |
Response:
Code Block | ||
---|---|---|
| ||
{ "adjustment_id": "46e10177-c3a3-4246-a33a-0c8306f3a9a6", "summary": { "desiredStatus": 33, "eligible": 2, "rejected": 2, "transactionscompleted": 60, "eligibletest": 60, "liveReconciledtransactions": 2, "completestransactionsWithDesiredStatus": 0, "rejectedisApiUser": 2true } } |
NOTE 1:
The system always records any Reconciliation process made via API or UI and this information can be find on the Survey dashboard → Reconciliation Tab
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
NOTE 2:
if you need to test the Live Reconciliation API and you want to create some test transactions, please ask your account manager or contact the PureSpectrum product team and they will give you access to a document that will allow you to create a transaction via API.
NOTE 3:
10pm PT is the absolute latest you can submit a reconciliation for it to be included in the next months invoice.