/
Live Reconciliation via API

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 change buyer_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 change buyer_rejects

 

Screenshot 2024-02-01 at 15.13.02.png

 

Related content