RevCent API V2
You are viewing the Version 2 API Docs. If you are looking for the Version 1 API Docs, please click here.
OpenAPI 3.1
The V2 API is a HTTP REST API, allowing only GET and POST requests. It conforms to the OpenAPI 3.1 standard. Download or import our OpenAPI 3.1 API specification: https://api.revcent.com/v2/openapi.json
V1 vs V2
The difference between the V1 API and V2 API is purely based on the need for an open standard interface. The V1 API does not follow an open standard. The V2 API follows the OpenAPI 3.1 standard, allowing developers and third parties to programmatically integrate using the specification file.
Which Should I Use?
If you are integrating with RevCent for the first time, we recommend using the V2 API and its specification. If you are currently using V1 API please continue to use it, as the V1 API will never be deprecated.
Whitelist RevCent
All requests from RevCent will use the following IP addresses:
34.224.171.255
52.3.146.218
54.174.155.188
Authentication
Use your RevCent API Key to make authenticated requests to the V2 API. The API Key is sent within the header of an API request. Read more about creating an API Key at our Knowledge Base
x-api-key Header
The x-api-key header should be present in every API request. Create an API account and retrieve the key in the web UI. We do not recommend using the root API keys which were created by RevCent when you signed up. Instead, create new keys for specific implementations.
curl -G https://api.revcent.com/v2 \ -H "x-api-key: YOUR_REVCENT_API_KEY" \ -H "Accept: application/json" \
Permissions
When creating an API key you can limit the key to perform only specific actions. We recommend you use the principle of least privilege, where you only enable specific API methods based on the use case per key.
Live/Test Keys
An API key can be set to Test mode or Live mode. This allows you to test the API and view results using the test/live mode toggle in the web app. Read more about Live vs Test mode at our Knowledge Base
Depending on the key used, RevCent will retrieve live or test items, as well as use the appropriate merchant gateway endpoint when processing payments. For example, if you use a test key for a payment request, RevCent will use the test endpoint for the merchant gateway and a live key will use the live merchant gateway endpoint.
Errors
The V2 API uses conventional HTTP status codes to indicate the success or failure of an API request. Codes in the 2xx range indicate success. Codes in the 4xx range indicate an error such a missing required parameter, a payment failure, etc. Codes in the 5xx range indicate an error with RevCent.
When a 4XX response is returned, the code property in the response body will indicate the type of error. All 4xx errors also include a message property that briefly explains the reason for failure, allowing for possible remedy and re-attempt.
It is recommended that you do not display raw API responses directly to visitors on checkout. Instead, use the HTTP status code and the response body code property to create a custom message to display to the visitor.
HTTP Status Codes
There are seven potential HTTP status codes which can be returned by the RevCent V2 API. Use status codes as the starting point to determine the outcome of a request, then use the body of the response.
Do not confuse a HTTP status code with the code property contained within the response body. A HTTP status code is a standard for HTTP requests. The code property contained within an API call response body is specific to RevCent.
HTTP Code | Type | Description |
---|---|---|
200 | Success | The request was successful, either for non-payment or payment requests. |
400 | Non-Payment Error | The API request contains an error and should be handled internally by the user. |
401 | Unauthorized | The API key is either missing, invalid or disabled. |
402 | Payment Error | A payment attempt failed, either due to decline, merchant error or fraud. |
404 | Not Found | A requested entity was not found. |
405 | Method Not Allowed | The requested HTTP method is not allowed. Only GET and POST requests are accepted. |
500 | RevCent Error | An error occurred within the RevCent system. |
Non-Payment Error
For non-payment errors the HTTP status code will be 400 and the code property will equal 0. The message property will describe the reason for the request error.
Body Code | Type | Description |
---|---|---|
0 | Generic Error | The request failed due to a user error. |
{ "code": 0, "error_code": "E0037", "message": "The payment profile you entered is invalid", "result": "Error" }
Payment Error
For failed payment attempts the HTTP status code will be 402, and the code property within the response body will indicate the type of payment failure. The gateway_raw_response property is the response from the gateway indicating why the payment attempt failed.
There are potential values for the code property within the response body, either 2, 3, or 4, indicating the type of gateway failure.
Body Code | Type | Description |
---|---|---|
2 | Payment Declined | The payment gateway declined the transaction. Use the gateway raw response to determine the exact error and reason. |
3 | Gateway Error | The payment gateway returned an error. Use the gateway raw response to determine the exact error and reason. |
4 | Gateway Hold | The payment gateway held the transaction. |
{ "code": 2, "message": "The gateway declined the transaction.", "gateway_raw_response": { "response": "2", "responsetext": "Insufficient funds", "authcode": " ", "transactionid": "123456789", "avsresponse": "Y", "cvvresponse": "M" }, "result": "Declined." }
Fraud Error
When either Sentinel or a third party service deems a request is fraud, the HTTP status code will be 402, and the code property will always equal 5. The fraud_detection_response property will provide detailed information about the fraud.
It is recommended that you do not display a fraud response directly to the visitor on checkout when fraud is detected. Instead, display a generic payment declined message to the fraudster, not letting them know you have detected fraud.
Additional payment attempts the fraudster makes will be immediately blocked by RevCent and never reach a gateway. RevCent wants fraudsters to continue to attempt payments, as RevCent will internally save information such as additional stolen cards and tracking visitor information.
Body Code | Type | Description |
---|---|---|
5 | Fraud Detected | Fraud was detected, either by Sentinel or third party service. |
{ "code": 5, "message": "Payment not processed.", "fraud_detected": true, "fraud_detection_created": [ "kyy9RE8HNo91lAZbwq0X" ], "fraud_detection_response": {...}, "result": "Payment request failed." }
Not Found Error
For not found errors the HTTP status code will be 404 and the code property will equal 0.
Body Code | Type | Description |
---|---|---|
0 | Generic Error | The request failed due to a user error. |
{ "code": 0, "message": "The requested item does not exist.", "result": "Not Found" }
Idempotent Requests
The RevCent API supports idempotency for safely retrying POST requests without performing the same specific operation twice.
This is useful for retrying disrupted requests while avoiding the chance of double charging a customer. To perform an idempotent request, provide the idempotency_key property within the request object. RevCent will check existing idempotency keys submitted within the past 24 hours for the API account. If an idempotency key match is found, the API request is immediately rejected and not saved.
Important: Only use idempotency keys if you know when and why to use them. Resubmitting the same idempotency key when purposely retrying a declined payment request will result in an error, and the retry payment will never be attempted.
idempotency_key
Provide the idempotency_key property in the JSON body of a POST request. The idempotency key must be at least 10 characters in length and can be up to 255 characters in length. We recommended you use V4 UUIDs.
curl -X POST https://api.revcent.com/v2/sales \ -H "x-api-key: YOUR_REVCENT_API_KEY" \ -H "Accept: application/json" \ -H "Content-Type: application/json" \ --data-raw '{ "idempotency_key": "2c74f520-2b7f-44ea" }'
Filtering
When retrieving a list of multiple items there are four required parameters as well as the option to include one or more filters. Each request has a specific set of filters available, so please refer to each request schema.
Required Parameters
Any GET requests which return more than one item, i.e. not ID specific, must include the date_start, date_end, limit and page URL parameters. Omitting any required parameters will result in an error.
URL Param | Type | Description |
---|---|---|
date_start | Unix Timestamp | The date range start date as a unix timestamp. |
date_end | Unix Timestamp | The date range end date as a unix timestamp. |
limit | Integer | The limit on the number of items to be returned. |
page | Integer | The requested page. |
curl -G https://api.revcent.com/v2/customers \ -H "x-api-key: YOUR_REVCENT_API_KEY" \ -H "Accept: application/json" \ -d date_start=1627876799 \ -d date_end=1628049599 \ -d limit=25 \ -d page=1
Multi-Value Filter
You can submit multiple values for the same filter by including the URL parameter more than once in a GET request. RevCent will group same URL parameters when filtering items.
In the example CURL request we wish to filter a list of customers by campaign using the campaign_filter parameter. However, we want to filter using multiple campaign IDs. We provide the campaign_filter URL parameter twice, each time being a specific campaign ID.
curl -G https://api.revcent.com/v2/customers \ -H "x-api-key: YOUR_REVCENT_API_KEY" \ -H "Accept: application/json" \ -d date_start=1627876799 \ -d date_end=1628049599 \ -d limit=25 \ -d page=1 \ -d campaign_filter="mJ1zZoOobEuP8pnWKXd1" \ -d campaign_filter="LYE26MW8Rlh5VbJmlp2l"
Metadata Filter
When making a get request for a list of items you have an optional metadata_filter parameter, which can be multi-value. Each metadata_filter parameter submitted is an object having a name and value property.
There are two methods when providing one or more metadata_filter parameters, however, you should only use one method in production. You can use a stringified JSON object, or use an array index i.e. metadata_filter[i][name] and metadata_filter[i][value].
In the two example CURL requests we show the different methods, where both methods would produce the same filtered result.
In the first example CURL request we wish to filter a list of sales by metadata using a stringified JSON object for each metadata_filter. Notice how we can include the metadata_filter multiple times with separate stringified JSON objects.
In the second example CURL request we use the array index method to match the name/value pair for each metadata_filter. Notice how we can include the metadata_filter multiple times, separating each filter name/value pair using an array index.
curl -G https://api.revcent.com/v2/sales \ -H "x-api-key: YOUR_REVCENT_API_KEY" \ -H "Accept: application/json" \ -d date_start=1627876799 \ -d date_end=1628049599 \ -d limit=25 \ -d page=1 \ --data-urlencode metadata_filter="{\"name\":\"facebook_ad\",\"value\":\"pets\"}" \ --data-urlencode metadata_filter="{\"name\":\"landing_page\",\"value\":\"v1\"}"
curl -G https://api.revcent.com/v2/sales \ -H "x-api-key: YOUR_REVCENT_API_KEY" \ -H "Accept: application/json" \ -d date_start=1627876799 \ -d date_end=1628049599 \ -d limit=25 \ -d page=1 \ --data-urlencode metadata_filter[0][name]="facebook_ad" \ --data-urlencode metadata_filter[0][value]="pets" \ --data-urlencode metadata_filter[1][name]="landing_page" \ --data-urlencode metadata_filter[1][value]="v1"
Customer ID Filter
Utilize the customer_id URL parameter when you wish to return a list of items specific to a customer.
Note: The customer_id filter is not a multi-value filter. It is limited to one customer ID and additional customer_id parameters will be ignored.
In the example CURL request, we wish to receive a list of transactions specific to the customer with an ID of 4r158EzJmmcVM69dNLkg. This will limit transactions only to this specific customer. If we omitted the customer_id parameter, all transactions will be returned regardless of customer.
curl -G https://api.revcent.com/v2/transactions \ -H "x-api-key: YOUR_REVCENT_API_KEY" \ -H "Accept: application/json" \ -d date_start=1627876799 \ -d date_end=1628049599 \ -d limit=25 \ -d page=1 \ -d customer_id="4r158EzJmmcVM69dNLkg"
Pagination
Pagination only applies to GET requests which return more than one item. All get requests which return multiple items will have page info contained in the response. Utilize the page info returned, along with the original URL date_start, date_end and limit parameters, to paginate.
URL Params
When requesting a list of items, the date_start, date_end, page and limit parameters are required. Utilize all four parameters, specifically the limit and page parameters, to paginate across multiple pages of results.
curl -G https://api.revcent.com/v2/customers \ -H "x-api-key: YOUR_REVCENT_API_KEY" \ -H "Accept: application/json" \ -d date_start=1627876799 \ -d date_end=1628049599 \ -d limit=25 \ -d page=1
Page Info
The response from a list request will contain the results array, as well as page info. The page info tells you the current page, the total number of pages and the number of items per page.
In the example response, we are using a limit of 25, currently at page 1, with a total of 4 pages. If you wanted the next page (page 2), you would use the same date_start and date_end URL params, along with limit=25 page=2.
{ "current_count": 25, "current_page": 1, "results": [...], "total_count": 79, "total_pages": 4 }