{"activeVersionTag":"latest","latestAvailableVersionTag":"latest","collection":{"info":{"_postman_id":"bb77b486-553b-41e6-834b-a7df14ee7d59","name":"OnePipe v2 - Documentation","description":"**NOTE:** For version 1 information, please see [OnePipe v1 documentation](https://v1.docs.onepipe.io)\n\nThis suite of APIs provides access to an array of financial services-related APIs like card charging, account debit, statement lookup, airtime purchase, bill payment, instant loans and KYC lookup services. Some of these services come from multiple providers like Polaris Bank, SunTrust Bank, Interswitch, Flutterwave and Paystack, but OnePipe wraps around them an abstraction layer with one major goal: To provide a consistent interface to integrators regardless of underlying service provider. That way, you can switch between providers at any time, based on quality of service, business justification, etc. without starting a new integration project or changing your systems in any way.\n\n# The principles behind OnePipe\n\n1. Ability to add multiple providers for the same service\n \n2. A standard unified API interface encapsulating all feature set available across providers\n \n3. Ability to setup as many apps as possible and determine which provider should fulfill the service for each app.\n \n\n\n\n# Want to try it quickly?\n\n1. Click the _run in postman_ button in the top right to import the collection.\n \n2. Familiarise yourself with the variables in the collection\n \n3. Try the various endpoints using the pre-loaded API keys\n \n\n# Getting access to the APIs\n\n### Sign up and customize the collection to use your own keys\n\nAccess to the APIs can only be via any of the OnePipe partners. We refer to them as \"hosts\". They are Banks with whom we have a special arrangement. Once granted access under their account, you will receive an invite email to set your password.\n\n1. Sign up [here](https://onepipe.io/start)\n \n2. Once approved, you will receive an email to set up your password\n \n3. Login and with newly set password, then generate your **API key** and **secret**\n \n4. Update the variables **api-key** and **secret-key** in the collection\n \n5. Change the `mock_mode` in any endpoint you want to try to `inspect`\n \n6. Use the tools [here](https://onepipe.io/tools/) to manage encryption of the secure elements\n \n7. Try as many API calls as required\n \n8. The bank will contact you about necessary documentations and KYC\n \n9. Once completed, the bank will enable you for go live\n \n10. Once approved, switch your calls between live and test as you see fit. This can be done per service/endpoint (from the console) or changing the `mock_mode` in the payload of your calls to `live`.\n \n\n# General API information\n\nThe APIs are fairly RESTful and are organized around the main services you would be interacting with. The base url sits at:\n\n```\nhttps://api.onepipe.io\n\n ```\n\n# The headers\n\nFor your API calls, include your API key in the Authorization header of every request you make. You can manage your API keys from your dashboard.\n\n_**Sample Authorization Header:**_\n\n```\nAuthorization: Bearer {api_key}\n\n ```\n\nAlso, every request requires you to provide a unique `request_ref` per call within the payload. Then You'd need to add a custom header called `Signature` which is an MD5 hash of that `request_ref` and your `api_secret` separated by a semi-colon. `;`. This just serves as a simple way to \"sign\" your payload as a second layer of security.\n\n_**Sample Signature Header:**_\n\n```\nSignature:MD5Hash(request_ref;client_secret)\n\n ```\n\nYour complete header for evey single call will look like:\n\n```\nContent-Type:application/json\nAuthorization:Bearer {{api_key}}\nSignature:{{MD5Hash(request_ref;client_secret)}}\n\n ```\n\n# The main operations you can perform\n\nThe operations you can perform on any OnePipe API falls into the following categories\n\n| **Type** | **Description** |\n| --- | --- |\n| **Transact** | This is the actual service or operation you are trying to execute. Your primary call. This typically sits at `{{baseUrl}}/v2/transact` |\n| **Validate** | Some transactions will require second level authentication/consent from the user. In this case the provider will response to your primary call with either `WaitingForOTP` or `PendingValidation`. Supply the validation required by calling `{{baseUrl}}/v2/transact/validate` |\n| **Query** | This is typically to get tha status of a prior transaction. Sits at `{{baseUrl}}/v2/transact/query` |\n| **Options** | Some services are such that you may need to 'probe' for a list of options before you can place the primary call. In these cases, this typically sits at `{{baseUrl}}/v2/transact/options` |\n| **Reverse** | Some services (or providers) support the capability to reverse a prior transaction. In this case, you can execute this at `{{baseUrl}}/v2/transact/reverse` |\n\n# What requests would look like\n\nFor all requests, you'd put a JSON object in the body of your API call. All payloads have the following high level construct:\n\n``` json\n {\n \"request_ref\":\"{{request_ref}}\", \n \"request_type\":\"transfer_funds\",\n \"auth\": {\n \"type\": \"bank.account | card | wallet\", \n \"secure\": \"{{encrypted(bank account details | card details | wallet)}}\",\n \"auth_provider\": \"Beeceptor\",\n \"route_mode\": null\n },\n \"transaction\": {\n \"mock_mode\": \"live\", \n \"transaction_ref\": \"{{transaction_ref}}\", \n \"transaction_desc\": \"A random transaction\", \n \"transaction_ref_parent\": null, \n \"amount\": 1000,\n \"customer\":{\n \"customer_ref\": \"{{customer_id}}\",\n \"firstname\": \"Uju\",\n \"surname\": \"Usmanu\",\n \"email\": \"ujuusmanu@gmail.com\",\n \"mobile_no\": \"234802343132\"\n },\n \"meta\":{\n \"a_key\":\"a_meta_value_1\",\n \"another_key\":\"a_meta_value_2\"\n },\n \"details\": {\n \"a_key\":\"a_value\",\n \"a_key\":\"a_value\"\n }\n }\n }\n\n ```\n\n| _Field_ | _Type_ | _Requirement_ | _Description_ |\n| --- | --- | --- | --- |\n| request_ref | string | compulsory | A unique value for every request made to the APIs. It uniquely identifies the API call itself. |\n| request_type | string | compulsory | This should be set to the service. e.g. `transfer_funds` |\n| auth.type | string | compulsory | Depending on the source of funds or unique authorization credentials. This can be set to either `bank.account`, `card`, `token`, `bvn` or `wallet` |\n| auth.secure | string | compulsory | This is the encrypted value of the `auth.type`. The format depends on the auth type, see [here](#encryption-of-secure-element) |\n| auth.provider | string | compulsory | This should be set to the name of the Provider you want to forward the request to |\n| auth.route_mode | string | N/A | This can be set to `null`. It informs OnePipe to \\[optionally\\] do some pre-processing before forwarding to the actual provider. |\n| transaction.mock_mode | string | optional | This can be set to either `live` or `inspect`. If left as null, value will fall back to the state of the service set on the console. |\n| transaction.transaction_desc | string | optional | Description of your transaction. For value based transactions, this could be the narration that will be seen in the account statement or store of value. |\n| transaction.transaction_ref_parent | string | optional | Takes value of a (parent) transaction reference. In case it's a transaction being retried. |\n| transaction.customer.customer_ref | string | compulsory | Unique identifier for customer |\n| transaction.customer.firstname | string | optional | First name of customer |\n| transaction.customer.surname | string | optional | Surname of customer |\n| transaction.customer.email | string | optional | Email address of customer |\n| transaction.customer.mobile_no | string | optional | Phone number of customer |\n| transaction.amount | int | compulsory | This is the amount (lower denomination) for value based transactions. |\n| transaction.transaction_ref | string | compulsory | Generate a unique transaction reference for every transaction call to OnePipe. |\n| transaction.meta | object | optional | Json object of your arbitrary transaction parameters |\n| transaction.details | object | varies per transaction type | JSON object of transaction type specific elements. The details required per transaction type will be explained in the docs for the transaction type. |\n\n# What responses would look like\n\nFor all responses, you'd get a JSON object in the body of the response you receive. All payloads have the following high level construct:\n\n``` json\n {\n \"status\": \"Successful\",\n \"message\": \"Transaction processed successfully\",\n \"data\": {\n \"provider_response_code\": \"00\",\n \"provider\": \"DemoProvider\",\n \"errors\": [],\n \"error\": {},\n \"provider_response\": {\n \"reference\": \"000022200225154318222333334432\",\n \"field_key\":\"field_value\",\n \"field_key\":\"field_value\",\n \"field_etc\": \"3056433222\",\n \"meta\":{\n \"fee_flat\": 0,\n \"fee_percent\": 0,\n \"commission_flat\": 0,\n \"commission_percent\": 0,\n \"field_key\":\"field_value\",\n \"field_key\":\"field_value\"\n }\n }\n }\n }\n\n ```\n\n- **status**: Indicates the state of the request, whether successful, failed or anything in between\n \n- **message**: Provides a text description of the state of the request and at times a message for the customer\n \n- **data**: Will contain much more details of the outcome of the request. The values within this could vary by request type or endpoint called but some standard elements would be in almost all calls\n \n- **provider_response_code**: The actual response code received from the underlying provider, e.g. `00` for Quickteller\n \n- **provider_response**: This contains the actual response from the provider, specific to the actual operation you are trying to perform. The elements here will vary based on the operation. This is the main area of interest.\n \n- **provider**: The provider that was used to process the request\n \n- **errors**: In case of a failed transaction, this contains the lists of errors that occurred while processing the transaction\n \n- **error**: This contains the most important error that hinders the successful completion of the transaction. \n We highly recommend that developers use the Errors field to determine the result of an API call. As an empty Errors node indicates a successful transaction.\n \n\n**NOTE**: Some API calls may have response elements that are only applicable to those API calls. You will see examples in the provided postman collection and across the documentation.\n\n# OnePipe standard status codes\n\n- **Successful**: For all requests that were successfully processed\n \n- **Failed**: If a request fails. Read the errors object(s)\n \n- **WaitingForOTP**: If a request requires OTP validation for completion.\n \n- **PendingValidation**: If a request requires other information to be supplied for completion.\n \n- **Processing**: If a transaction request is still in a processing state and needs to be subsequently queried.\n \n- **OptionsDelivered**: Applicable only for services that support some form of options processing.\n \n- **InvalidID**: If an ID being looked up by service is not valid.\n \n- **Fraud**: If a request is flagged as suspicious.\n \n- **Duplicate**: If a similar request has been made earlier within a stipulated time frame of 5 minutes.\n \n- **PendingFulfilment**: The transaction requires extra steps from the customer.\n \n- **\\[Anything else\\]**: This would vary per endpoint called. Applicable values would be in the documentation for that endpoint.\n \n\n# HTTP Status Codes\n\n- **200**: Request was processed \"conclusively\". Not to be taken as a successful status. Always read the `response.status` object for actual processing status. Also note that the description field on the response can contain further steps to be carried on this transaction.\n \n- **400**: Data validation error occurred due to inconsistent data supplied by the client\n \n- **401**: Invalid request authorization, which might be due to invalid API key or the client is not registered for the service being accessed.\n \n- **500**: An internal server error at our End, this should be reported if it persists.\n \n\n# Encryption of Secure element\n\nAs mentioned, the `auth.secure` enlement needs to contain the encrypted value of authorization details or customer credentials. e.g. card details. Encrypt the value using the Triple DES Encryption Algorithm with your Client application secret key as the encryption key.\n\nE.g.\n\n#### When it's a `card`, it should be:\n\n```\nTripleDES.encrypt(\"{card.Pan};{card.Cvv};{card.Expdate};{card.Pin}\",secretKey)\n\n ```\n\n#### If it's `bank.account` , it should be:\n\n```\nTripleDES.encrypt(\"{accountNumber};{bankCBNCode}\",secretKey)\n\n ```\n\n#### If it's `wallet` , it should be:\n\n```\nTripleDES.encrypt(\"{walletNumber};{providerCode}\",secretKey)\n\n ```\n\n#### If it's `airtime` , it should be:\n\n```\nTripleDES.encrypt(\"{phoneNumber};{telcoCode}\",secretKey)\n\n ```\n\n#### If it's `voucher` , it should be:\n\n```\nTripleDES.encrypt(\"{voucherCode};{providerCode}\",secretKey)\n\n ```\n\n#### If it's `bvn` , it should be:\n\n```\nTripleDES.encrypt(\"{bvn}\",secretKey)\n\n ```\n\n#### If it's `basic` , it should be:\n\n```\nTripleDES.encrypt(\"{userName};{password}\",secretKey)\n\n ```\n\n#### If it's `custom` , it should be:\n\n```\nTripleDES.encrypt(\"{ref}\",secretKey)\n\n ```\n\n**NOTE** Expiry date is MMyy\n\n## Sample encryption in Java\n\n```\nMessageDigest md = MessageDigest.getInstance(\"md5\");\nbyte[] digestOfPassword = md.digest(key.getBytes(\"UTF-16LE\"));\nbyte[] keyBytes = Arrays.copyOf(digestOfPassword, 24);\nfor (int j = 0, k = 16; j < 8;) {\n keyBytes[k++] = keyBytes[j++];\n}\nSecretKey secretKey = new SecretKeySpec(keyBytes, 0, 24, \"DESede\");\nIvParameterSpec iv = new IvParameterSpec(new byte[8]);\nCipher cipher = Cipher.getInstance(\"DESede/CBC/PKCS5Padding\");\ncipher.init(Cipher.ENCRYPT_MODE, secretKey, iv);\nbyte[] plainTextBytes = toBeEncrypted.getBytes(\"UTF-16LE\");\nbyte[] cipherText = cipher.doFinal(plainTextBytes);\nString output = new String(Base64.encodeBase64(cipherText));\nreturn output;\n\n ```\n\n## Sample encryption in C-Sharp\n\n```\nstring encryptedText = \"\";\nMD5 md5 = new MD5CryptoServiceProvider();\nTripleDES des = new TripleDESCryptoServiceProvider();\ndes.KeySize = 128;\ndes.Mode = CipherMode.CBC;\ndes.Padding = PaddingMode.PKCS7;\nbyte[] md5Bytes = md5.ComputeHash(Encoding.Unicode.GetBytes(key));\nbyte[] ivBytes = new byte[8];\ndes.Key = md5Bytes;\ndes.IV = ivBytes;\nbyte[] clearBytes = Encoding.Unicode.GetBytes(TextToEncrypt);\nICryptoTransform ct = des.CreateEncryptor();\nusing (MemoryStream ms = new MemoryStream())\n{\n using (CryptoStream cs = new CryptoStream(ms, des.CreateEncryptor(), CryptoStreamMode.Write))\n {\n cs.Write(clearBytes, 0, clearBytes.Length);\n cs.Close();\n }\n encryptedText = Convert.ToBase64String(ms.ToArray());\n}\nreturn encryptedText;\n\n ```\n\n## Sample encryption in PHP\n\n```\nfunction EncryptV2($encryption_key,$data)\n{\n $method = \"des-ede3-cbc\";\n $source = mb_convert_encoding($encryption_key, 'UTF-16LE', 'UTF-8');\n $encryption_key = md5($source, true);\n $encryption_key .= substr($encryption_key, 0, 16);\n $iv = \"\\0\\0\\0\\0\\0\\0\\0\\0\";\n $encData = openssl_encrypt($data,$method, $encryption_key, $options=OPENSSL_RAW_DATA, $iv);\n echo base64_encode($encData);\n}\n\n ```\n\n## Sample encryption in Node.js\n\n```\nconst crypto = require('crypto');\nfunction encrypt(secretKey, plainText) {\n const bufferedKey = Buffer.from(secretKey, 'utf16le');\n const key = crypto.createHash('md5').update(bufferedKey).digest();\n const newKey = Buffer.concat([key, key.slice(0, 8)]);\n const IV = Buffer.alloc(8, '\\0');\n const cipher = crypto.createCipheriv('des-ede3-cbc', newKey, IV).setAutoPadding(true);\n return cipher.update(plainText, 'utf8', 'base64') + cipher.final('base64');\n}\n\n ```\n\nNB: If the snippet of your preferred language is not available, you can make use of our [Encryption Service on Docker](https://hub.docker.com/r/onepipe/encryption)\n\n# Switching providers for a service\n\nAll services subscribed to in your application are attached to providers that will end up fulfilling such service(s) on request. You can switch providers as you wish by managing the application from your dashboard and editing the service details. Also, for some endpoints, you can explicitly set the provider you would like to be used in the request payload. You would see examples in the documentation for the endpoints that support this.\n\n# Bank CBN Codes\n\nAnywhere bank codes are required in the API specification (`bank_code`), this refers to the CBN bank codes. Details of all bank codes can be found [here](https://onepipe.atlassian.net/wiki/spaces/PUB/pages/2042888195/CBN+BANK+CODES).\n\n# Test cards\n\n- Paystack - Test cards [here](https://developers.paystack.co/docs/test-cards)\n \n- Flutterwave - Test cards [here](https://developer.flutterwave.com/docs/test-cards)\n \n- Quickteller - Test cards [here](https://sandbox.interswitchng.com/docbase/docs/interswitch-payment-gateway-mobile-inappsdk-implementation/test-cards/) => Pan:5061040000000000306 Pin:1234 CVV:123 EXP:1901\n \n\n# Scheduled transactions\n\nScheduler works great with all of OnePipe existing services be it purchase services, payment services or credit services. You can set up a schedule that works best for you and your customers. With this provider, re-occuring transactions can be scheduled to be processed on a regular basis by using the additional `meta` tag that is present for all OnePipe services.\n\nThis will enable you to process future transactions for different time periods such as daily, weekly, monthly and more! for example, you might want to be able to collect monthly payments from your customers or schedule for automatic transfers to account(s) on a regular basis.\n\n#### Please be sure to have gone through....\n\nFirst, please be familiar with below documentation on OnePipe services...\n\n- [The headers](#the-headers)\n \n- [Main API operations](#the-main-operations-you-can-perform)\n \n- [Typical OnePipe requests](#what-requests-would-look-like)\n \n- [Typical OnePipe responses](#what-responses-would-look-like)\n \n- [Encryption of the secure element](#encryption-of-secure-element)\n \n\n#### Post Scheduled Transaction\n\nWith this call `transact/schedule`, you can send a request to be processed in a future date and/or at regular time intervals. You will have to provide your authorisation details and OnePipe will in turn forward to the provider’s dedicated implementation for execution on the specified date. On job complete, transaction notification will be sent to the customer via the client webhook. For example: Buy N1000 airtime every 7 days (weekly) using the `buy_airtime` purchase service.\n\n#### Sequence of call\n\n1. Call `v2/transact/schedule` with the right auth details and request_type.\n \n2. Provider responds with any of the completion codes `Successful` or `Failed`.\n \n\n**Please note**:Please refer to OnePipe v2 documentation to understand the several request_types available which are grouped into different segments for example, payment services, messaging services and more!). You will only have to include three extra tags that start with the `repeat_` keyword. These tags must be specified within the `meta` tag of the payload in order to schedule a future request.\n\n#### Request Sample for 'transact/schedule'\n\nFor all schedule requests, you'd put a JSON object in the body of your API call. All payloads have the following high level construct:\n\n``` json\n {\n \"request_ref\":\"{{request_ref}}\", \n \"request_type\":\"{{request_type}}\",\n \"auth\": {\n \"type\": \"Basic\", \n \"secure\": \"{{encrypted(password)}}\",\n \"auth_provider\": \"Scheduler\"\n },\n \"transaction\": {\n \"mock_mode\": \"inspect\", \n \"transaction_ref\": \"{{transaction_ref}}\", \n \"transaction_desc\": \"A random scheduled transaction\", \n \"transaction_ref_parent\": null, \n \"amount\": 1000,\n \"customer\":{\n \"customer_ref\": \"{{customer_id}}\",\n \"firstname\": \"Demo\",\n \"surname\": \"Demo\",\n \"email\": \"demo@gmail.com\",\n \"mobile_no\": \"234802343132\"\n },\n \"meta\":{\n \"repeat_frequency\":\"once | hourly | daily | weekly | monthly | yearly\",\n \"repeat_start\":\"2021-02-27-18-50-00\"\n \"repeat_target_provider\":\"Payant\",\n \"exclude\":\"Sunday\"\n },\n \"details\": {\n \"a_key\":\"a_value\",\n \"a_key\":\"a_value\"\n }\n }\n }\n\n ```\n\n| _Field_ | _Type_ | _Requirement_ | _Description_ |\n| --- | --- | --- | --- |\n| repeat_frequency | string | compulsory | The re-occuring time period which is a limited set of options. This can be set to either `once`, `hourly`, `daily`, `weekly`, `monthly` or `yearly` |\n| request_start | string | compulsory | The datetime stamp to initiate first transaction where the format is `YYYY-MM-DD-HH-MM-SS` |\n| repeat_target_provider | string | compulsory | The preferred provider to process the transactions during execution on a regular basis |\n| exclude | string | optional | Exclude a certain time in the frequency. |\n\n#### Response Sample for 'transact/schedule'\n\nFor all schedule responses, you'd get a JSON object in the body of the response you receive. All payloads have the following high level construct:\n\n``` json\n {\n \"status\": \"Successful\",\n \"message\": \"Operation was successful\",\n \"data\": {\n \"provider_response_code\": \"00\",\n \"provider\": \"Scheduler\",\n \"errors\": [],\n \"error\": {},\n \"provider_response\": \"null\"\n }\n }\n\n ```\n\n- `status`: The state of the request, whether successful or failed\n \n- `message`: Provides a text description of the state of the request\n \n- `data`: This will contain much more details of the outcome of the request which will include the response code from the provider and any error objects if present\n \n- `provider_response_code`: The actual response code received from the Scheduler provider, e.g. `00` for Successful requests\n \n- `provider_response`: This contains additional response from the provider if any specific to the actual operation being performed.\n \n- `provider`: The provider that was used to process the request. This will always be `Scheduler`.\n \n- `errors`: In case of a failed transaction, this contains the lists of errors that occurred while processing the transaction\n \n- `error`: This contains the most important error that hinders the successful completion of the transaction. \n We highly recommend that developers use the Errors field to determine the result of an API call. As an empty Errors node indicates a successful transaction.\n \n\n#### Interpreting the response\n\n- Read the reponse `status` and `message`\n \n\n#### Possible status values\n\n- **Successful**: Success\n \n- **\\[Anything else\\]**: Error. Read the errors object(s)\n \n\n#### Reverse Scheduled Transaction\n\nWith this service `v2/transact/schedule/reverse`, you can cancel a previously scheduled request. Upon successful response from the Scheduler Provider, the future re-occuring transactions will not be executed on a regular basis. To continue with the schedule after termination, you will have to post a new request.\n\n#### Sequence of call\n\nNow, here's the call sequence specific to this service...\n\n1. Call `/transact/schedule/reverse` with the right auth details and `request_type`.\n \n2. Provider responds with any of the completion codes `Successful` or `Failed`.\n \n\n**Please note**:Please refer to OnePipe v2 documentation to understand the several request_types available which are grouped into different segments for example, payment services, messaging services and more!). You will only have to include three extra tags that start with `repeat_` specified in more detail below inside the `meta` tag of the payload to schedule a future request.\n\n#### Request Sample for 'transact/schedule/reverse'\n\nFor all reverse requests, you'd put a JSON object in the body of your API call. All payloads have the following high level construct:\n\n``` json\n {\n \"request_ref\":\"{{request_ref}}\", \n \"request_type\":\"{{request_type}}\",\n \"transaction\": { \n \"transaction_ref\": \"{{transaction_ref}}\", \n \"transaction_desc\": \"A sample transaction to be reversed\"\n }\n }\n\n ```\n\n| _Field_ | _Type_ | _Requirement_ | _Description_ |\n| --- | --- | --- | --- |\n| repeat_ref | string | compulsory | A unique reference for this API call |\n| request_type | string | compulsory | Depends on what the provider requires to reverse the request. This has to match the `request_type` of the original transaction. For instance, if a request was initially sent to schedule `buy_airtime` service, then the reverse call will also be `buy_airtime`. |\n| transaction.transaction_ref | string | compulsory | This is the original `transaction_ref` for the initial schedule request which is to be terminated |\n| transaction.transaction_desc | string | compulsory | A short description or narration |\n\n#### Response Sample for 'transact/schedule/reverse'\n\nFor all reverse responses, you'd get a JSON object in the body of the response you receive. All payloads have the following high level construct:\n\n``` json\n {\n \"status\": \"Successful\",\n \"message\": \"Operation was successful\",\n \"data\": {\n \"provider_response_code\": \"00\",\n \"provider\": \"Scheduler\",\n \"errors\": [],\n \"error\": {},\n \"provider_response\": \"null\"\n }\n }\n\n ```\n\n- `status`: The state of the request, whether successful or failed\n \n- `message`: Provides a text description of the state of the request\n \n- `data`: This will contain much more details of the outcome of the request which will include the response code from the provider and any error objects if present\n \n- `provider_response_code`: The actual response code received from the Scheduler provider, e.g. `00` for Successful requests\n \n- `provider_response`: This contains additional response from the provider if any specific to the actual operation being performed.\n \n- `provider`: The provider that was used to process the request. This will always be `Scheduler`.\n \n- `errors`: In case of a failed transaction, this contains the lists of errors that occurred while processing the transaction\n \n- `error`: This contains the most important error that hinders the successful completion of the transaction. \n We highly recommend that developers use the Errors field to determine the result of an API call. As an empty Errors node indicates a successful transaction.\n \n\n#### Interpreting the response\n\n- Read the reponse `status` and `message`\n \n\n#### Possible status values\n\n- **Successful**: Success\n \n- **\\[Anything else\\]**: Error. Read the errors object(s)","schema":"https://schema.getpostman.com/json/collection/v2.0.0/collection.json","isPublicCollection":false,"owner":"6358444","team":242895,"collectionId":"bb77b486-553b-41e6-834b-a7df14ee7d59","publishedId":"SzmiWwB3","public":true,"publicUrl":"https://v2.docs.onepipe.io","privateUrl":"https://go.postman.co/documentation/6358444-bb77b486-553b-41e6-834b-a7df14ee7d59","customColor":{"top-bar":"212121","right-sidebar":"303030","highlight":"00B1E5"},"documentationLayout":"classic-double-column","customisation":{"metaTags":[{"name":"description","value":""},{"name":"title","value":""}],"appearance":{"default":"system_default","themes":[{"name":"dark","logo":null,"colors":{"top-bar":"212121","right-sidebar":"303030","highlight":"00B1E5"}},{"name":"light","logo":null,"colors":{"top-bar":"212121","right-sidebar":"303030","highlight":"00B1E5"}}]}},"version":"8.10.1","publishDate":"2025-02-22T10:44:33.000Z","activeVersionTag":"latest","documentationTheme":"light","metaTags":{"title":"","description":""},"logos":{"logoLight":null,"logoDark":null}},"statusCode":200},"environments":[],"user":{"authenticated":false,"permissions":{"publish":false}},"run":{"button":{"js":"https://run.pstmn.io/button.js","css":"https://run.pstmn.io/button.css"}},"web":"https://www.getpostman.com/","team":{"logo":"https://res.cloudinary.com/postman/image/upload/t_team_logo_pubdoc/v1/team/a27a425324c006dd1f53f07becf2d5c16478567dd1dde25001728b716c749aa8","favicon":"https://res.cloudinary.com/postman/image/upload/v1547191824/team/zjhn0lwn04wuxbe90rhq.ico"},"isEnvFetchError":false,"languages":"[{\"key\":\"csharp\",\"label\":\"C#\",\"variant\":\"HttpClient\"},{\"key\":\"csharp\",\"label\":\"C#\",\"variant\":\"RestSharp\"},{\"key\":\"curl\",\"label\":\"cURL\",\"variant\":\"cURL\"},{\"key\":\"dart\",\"label\":\"Dart\",\"variant\":\"http\"},{\"key\":\"go\",\"label\":\"Go\",\"variant\":\"Native\"},{\"key\":\"http\",\"label\":\"HTTP\",\"variant\":\"HTTP\"},{\"key\":\"java\",\"label\":\"Java\",\"variant\":\"OkHttp\"},{\"key\":\"java\",\"label\":\"Java\",\"variant\":\"Unirest\"},{\"key\":\"javascript\",\"label\":\"JavaScript\",\"variant\":\"Fetch\"},{\"key\":\"javascript\",\"label\":\"JavaScript\",\"variant\":\"jQuery\"},{\"key\":\"javascript\",\"label\":\"JavaScript\",\"variant\":\"XHR\"},{\"key\":\"c\",\"label\":\"C\",\"variant\":\"libcurl\"},{\"key\":\"nodejs\",\"label\":\"NodeJs\",\"variant\":\"Axios\"},{\"key\":\"nodejs\",\"label\":\"NodeJs\",\"variant\":\"Native\"},{\"key\":\"nodejs\",\"label\":\"NodeJs\",\"variant\":\"Request\"},{\"key\":\"nodejs\",\"label\":\"NodeJs\",\"variant\":\"Unirest\"},{\"key\":\"objective-c\",\"label\":\"Objective-C\",\"variant\":\"NSURLSession\"},{\"key\":\"ocaml\",\"label\":\"OCaml\",\"variant\":\"Cohttp\"},{\"key\":\"php\",\"label\":\"PHP\",\"variant\":\"cURL\"},{\"key\":\"php\",\"label\":\"PHP\",\"variant\":\"Guzzle\"},{\"key\":\"php\",\"label\":\"PHP\",\"variant\":\"HTTP_Request2\"},{\"key\":\"php\",\"label\":\"PHP\",\"variant\":\"pecl_http\"},{\"key\":\"powershell\",\"label\":\"PowerShell\",\"variant\":\"RestMethod\"},{\"key\":\"python\",\"label\":\"Python\",\"variant\":\"http.client\"},{\"key\":\"python\",\"label\":\"Python\",\"variant\":\"Requests\"},{\"key\":\"r\",\"label\":\"R\",\"variant\":\"httr\"},{\"key\":\"r\",\"label\":\"R\",\"variant\":\"RCurl\"},{\"key\":\"ruby\",\"label\":\"Ruby\",\"variant\":\"Net::HTTP\"},{\"key\":\"shell\",\"label\":\"Shell\",\"variant\":\"Httpie\"},{\"key\":\"shell\",\"label\":\"Shell\",\"variant\":\"wget\"},{\"key\":\"swift\",\"label\":\"Swift\",\"variant\":\"URLSession\"}]","languageSettings":[{"key":"csharp","label":"C#","variant":"HttpClient"},{"key":"csharp","label":"C#","variant":"RestSharp"},{"key":"curl","label":"cURL","variant":"cURL"},{"key":"dart","label":"Dart","variant":"http"},{"key":"go","label":"Go","variant":"Native"},{"key":"http","label":"HTTP","variant":"HTTP"},{"key":"java","label":"Java","variant":"OkHttp"},{"key":"java","label":"Java","variant":"Unirest"},{"key":"javascript","label":"JavaScript","variant":"Fetch"},{"key":"javascript","label":"JavaScript","variant":"jQuery"},{"key":"javascript","label":"JavaScript","variant":"XHR"},{"key":"c","label":"C","variant":"libcurl"},{"key":"nodejs","label":"NodeJs","variant":"Axios"},{"key":"nodejs","label":"NodeJs","variant":"Native"},{"key":"nodejs","label":"NodeJs","variant":"Request"},{"key":"nodejs","label":"NodeJs","variant":"Unirest"},{"key":"objective-c","label":"Objective-C","variant":"NSURLSession"},{"key":"ocaml","label":"OCaml","variant":"Cohttp"},{"key":"php","label":"PHP","variant":"cURL"},{"key":"php","label":"PHP","variant":"Guzzle"},{"key":"php","label":"PHP","variant":"HTTP_Request2"},{"key":"php","label":"PHP","variant":"pecl_http"},{"key":"powershell","label":"PowerShell","variant":"RestMethod"},{"key":"python","label":"Python","variant":"http.client"},{"key":"python","label":"Python","variant":"Requests"},{"key":"r","label":"R","variant":"httr"},{"key":"r","label":"R","variant":"RCurl"},{"key":"ruby","label":"Ruby","variant":"Net::HTTP"},{"key":"shell","label":"Shell","variant":"Httpie"},{"key":"shell","label":"Shell","variant":"wget"},{"key":"swift","label":"Swift","variant":"URLSession"}],"languageOptions":[{"label":"C# - HttpClient","value":"csharp - HttpClient - C#"},{"label":"C# - RestSharp","value":"csharp - RestSharp - C#"},{"label":"cURL - cURL","value":"curl - cURL - cURL"},{"label":"Dart - http","value":"dart - http - Dart"},{"label":"Go - Native","value":"go - Native - Go"},{"label":"HTTP - HTTP","value":"http - HTTP - HTTP"},{"label":"Java - OkHttp","value":"java - OkHttp - Java"},{"label":"Java - Unirest","value":"java - Unirest - Java"},{"label":"JavaScript - Fetch","value":"javascript - Fetch - JavaScript"},{"label":"JavaScript - jQuery","value":"javascript - jQuery - JavaScript"},{"label":"JavaScript - XHR","value":"javascript - XHR - JavaScript"},{"label":"C - libcurl","value":"c - libcurl - C"},{"label":"NodeJs - Axios","value":"nodejs - Axios - NodeJs"},{"label":"NodeJs - Native","value":"nodejs - Native - NodeJs"},{"label":"NodeJs - Request","value":"nodejs - Request - NodeJs"},{"label":"NodeJs - Unirest","value":"nodejs - Unirest - NodeJs"},{"label":"Objective-C - NSURLSession","value":"objective-c - NSURLSession - Objective-C"},{"label":"OCaml - Cohttp","value":"ocaml - Cohttp - OCaml"},{"label":"PHP - cURL","value":"php - cURL - PHP"},{"label":"PHP - Guzzle","value":"php - Guzzle - PHP"},{"label":"PHP - HTTP_Request2","value":"php - HTTP_Request2 - PHP"},{"label":"PHP - pecl_http","value":"php - pecl_http - PHP"},{"label":"PowerShell - RestMethod","value":"powershell - RestMethod - PowerShell"},{"label":"Python - http.client","value":"python - http.client - Python"},{"label":"Python - Requests","value":"python - Requests - Python"},{"label":"R - httr","value":"r - httr - R"},{"label":"R - RCurl","value":"r - RCurl - R"},{"label":"Ruby - Net::HTTP","value":"ruby - Net::HTTP - Ruby"},{"label":"Shell - Httpie","value":"shell - Httpie - Shell"},{"label":"Shell - wget","value":"shell - wget - Shell"},{"label":"Swift - URLSession","value":"swift - URLSession - Swift"}],"layoutOptions":[{"value":"classic-single-column","label":"Single Column"},{"value":"classic-double-column","label":"Double Column"}],"versionOptions":[],"environmentOptions":[{"value":"0","label":"No Environment"}],"canonicalUrl":"https://v2.docs.onepipe.io/view/metadata/SzmiWwB3"}