{"activeVersionTag":"latest","latestAvailableVersionTag":"latest","collection":{"info":{"_postman_id":"18819512-a78c-40a4-8507-3c10ac07127a","name":"OTP Service Public EN API v1.1","description":"**OTP service** is a SaaS software aimed at individuals and companies who need to propose a document to be signed by natural persons: customers, collaborators, etc.\n\n## Compatibility and URL\n\nThe API v1.1 is backward-compatible with API v1, so URLs remain unchanged.\n\nTheir prefix is still `/api/v1/`\n\nWhen the documentation refers to a \"deprecated API,\" it means API v1 with its parameters, which continue to work and are automatically converted to new API parameters.\n\n## Parties\n\nThe involved parties are:\n\n- the _Proposer_: (the entity that wants to submit a document for signature, usually the client of OTP Service)\n    \n- one or more signatories (the clients, collaborators, etc. of the proposer)\n    \n- OTP service as a third party, being the provider of the signature tool.\n    \n\nFor more details, please refer to the `Definitions` section.\n\n## Types of Signature\n\nWe manage both Simple Electronic Signature (SES) and Advanced Electronic Signature (AES).\n\n### Simple Electronic Signature (SES)\n\nSES is suitable for purposes where the legal aspect is not critical: when it is essential to know if and when the signer receives, reads, and approves the document. It is a very quick process for both the _Proposer_ and the signer.\n\n### Advanced Electronic Signature (AES)\n\nOur solution meets all requirements of the current Italian regulation (DPCM 22/02/2013 from Article 55 to 63). Compared to SES, AES require that each signer should be recognized, requiring photo capture or in-person verification. This process requires more data (compared to SES), and if remote recognition is chosen, the process can only be completed after the _Proposer_’s operator, through our interface, validates the data. The procedures following the first are as fast as the FS, as long as some personal details do not change. In this case, a new recognition session is triggered, either in person or remote based on who modified the data, whether the proposer or the signatory.\n\n## Definitions\n\nA `dossier` is the set of information required to bring a document to signature.\n\nThe `signers` are the individuals added to the directory (automatically done after creating the first practice). These data can be updated at any time, and changes will take effect from the next dossier.\n\nThe `recipients` of the dossier are the signers to whom the document for signature will be presented. In other words, they are \"clones\" of the signers and are immutable over time.\n\nThe `document to be signed` is what is sent to the recipients and is uploaded by the _Proposer_.\n\nThe `signature points` define the positions in the document where the recipients can place their signature. For a given recipient, a signature point may be required, optional, or unavailable for signature, as it is reserved for other recipients.\n\nThe `signed document` is generated by otpservice.io at the conclusion of the signing process. Essentially, it is the document to be signed with an added summary of the process and the _electronic seal_ by OTP service.\n\nAlso see the `Main Entities` section for a more detailed description.\n\n# The Workflow\n\nThe workflow varies depending on the type of signature and chosen options.  \nThe type of signature has been described above, while the options will be explained in the \"Process Configuration\" section. API usage is covered in its respective section. Below is a brief description of the process steps.\n\n## Step 1 - Proposer\n\n1.A The _Proposer_ prepares the requirements to create the dossier:\n\n- prepares the document on his own to be presented to the signers in PDF format (for example, a Word document saved as PDF)\n    \n- collects the data of the signer(s), the quantity varies based on the chosen signature type: few data for SES, significantly more for AES. The proposer can either provide the data upfront or allow the signer to input them during the final recognition step.\n    \n\n1.B The _Proposer_ creates the practice with the data of the signer(s), and based on the chosen options, OTP Service will notify each recipient via email or SMS.\n\nThe email will contain:\n\n- an introduction of the proposer (logo and colours) and instructions\n    \n- the PDF file attachment and the hash fingerprint (to verify that it is the same file)\n    \n- a web link to the dossier so each signer can proceed with the signature\n    \n\nThe SMS will only contain the link to the signing page for the document, which can be read and downloaded before signing.\n\n## Step 2 - Signer\n\nThe signer receives an email with a clear button to proceed or an SMS, and by clicking on the link, he will arrive to a web page with an invitation to continue.\n\nThe UI guides the signer through the process based on the chosen signature type.\n\n## Step 3 - OTP Service\n\nOTP Service generates the signed PDF, if the generation option is active; otherwise, it waits for the proposer to upload it via a specific endpoint.  \nThe signed document is a regular PDF file with a graphical and textual indication of the process and the OTP Service electronic seal. OTP Service uses its fingerprint to calculate the hash that ensures process immutability, in particular:\n\n- the original PDF before signing\n    \n- the signed PDF\n    \n- the actions of each signer and the data/contact information used during the signing process\n    \n\nWe call this hash the \"Signature Verification Code,\" which can be entered in our UI (accessible from the public page [https://app.otpservice.io/signature](https://app.otpservice.io/signature)) to allow interested parties to verify the signing process and, if needed, download the document.\n\n# Workflow Configuration\n\nThe _Proposer_ already registered with OTP Service must:\n\n1. Through the UI, enter the profile -> organization and ensure the name is correct (verify that it is not the default name).\n    \n2. Customize with logo and colors to give your communications your own touch.\n    \n\nOptionally, advanced options can be modified through the UI. The same can be overridden with each dossier creation (except sms_allowed) using the specified label:\n\n- `send_unsigned_document`: Sends the initial email with the document for signing. If false, the _Proposer_ can send it independently. The dossier remains in the \"just_created\" state. If true, the dossier state becomes \"notified.\"\n    \n- `send_signed_document_by_email`: Sends the signed document via email.\n    \n- `send_signed_document_by_sms`: Sends the link to download the signed document via SMS.\n    \n- ~~send_signed_document~~: Sends the final email with the signed document. If false, the _Proposer_ can handle it independently. _**Deprecated.**_ _Use specific attributes for each sending method._\n    \n- `duplicate_documents_allowed`: If true, allows documents with the same fingerprint to be uploaded, useful if the proposer uses generic documents. Otherwise, it is best to avoid this to prevent the risk of sending an already-used document.\n    \n- `sms_allowed`: Default is true, as AES requires it. However, if only SES is of your interest, setting it to false helps to block SMS usage and reduce dossier costs.\n    \n\n# Signer UI and Recipient UUID\n\nWhen the practice reaches the \"Notified\" state (see the state section), an email is sent to the signers with instructions and a link to start the signing process. When the signer opens the link, a self-authenticated session by the token is initiated, with a validity period tied to the dossier.\n\nThe link has a path like this:\n\n```\napi.otpservice.io/sign/recipient/{{uuidRecipient}}\n\n ```\n\nThe API responses do not contain the uuidRecipient parameter required to compose the URL above. The rationale is that this URL is contained only in the messages sent by OTP Service to the signer. However if the creators of the dossier wants to send email and SMSes to the signer, with the link to the signing page, they must receive that uuid in the JSON responses. To enable this feature plese contact our Support team (link Contact Us in the footer of the web app). All API responses add the \"uuid\" parameter to the recipients data in their responses once the functionality is enabled.\n\n# Embedded Mode\n\nIt is possible to embed the signer’s UI within your own management system or in a UI directed at your clients. To do so, simply pass the `embedded` parameter.\n\n``` markdown\nhttps://app.otpservice.io/sign/recipient/{{uuidRecipient}}?embedded=true\n\n ```\n\nTo obtain the uuidRecipient please follow the procedure described in the section above.\n\nThe embedded method is at the user's discretion. This example demonstrates the use of an iframe (the link is for illustrative purposes only).\n\nIt is important to note that the embedded mode modifies the navigation process to better suit the requirements typically associated with integration into a management system:\n\n- The signing landing page shown to the signatory is omitted. This is an introductory page that has no relevance in an already initiated process.\n    \n- For \"Advanced Electronic Signature\" workflows, we do not display the top stepper that summarizes the three data collection sessions (AES terms, data form, and photo capture). Additionally, the step that presents the data form is omitted if all required data is already present. This is because such data is usually gathered by the proposing system.\n    \n- The concluding messages are specific to this mode.\n    \n\nTherefore, as described, it is possible to also manage AES dossiers. But how is the negative outcome of recognition handled? It should be noted that more details can be found in the section that describes recognition. The anomaly is reported to the signatory, who will receive a link to return to the dossier. Since it is not in embedded mode, the signatory will see the full UI and will be able to modify the flagged data. The proposer can receive the updates if they activate callbacks (see the callback section for the recipient).\n\nIn embedded mode, an additional configuration is available. By passing the `sign_point_navigation` parameter, the \"Go to next signing point\" button can be displayed, as found in the classic mode stepper. The syntax is:\n\n```\nhttps://app.otpservice.io/sign/recipient/{{uuidRecipient}}?embedded=true&sign_point_navigation=true\n\n ```\n\nBy default, in embedded mode, that button is hidden.\n\n# Main Entities\n\nThe main entity is the `Customer`, which represents your organization as a client of the OTP Service.  \nThe `Dossier` is the record in which the personal data of the `Signer` (signatory) is \"frozen\" by creating a clone, the `Recipient` (signer -> recipient), who remains unchanged over time.\n\nWhen a dossier is created, the OTP Service checks for the existence of the signer and either updates it or creates it if it is new (searched by phone number and/or email). Then it clones the signer, creating the recipient. Therefore, if the personal data is new, both signer and recipient are created; otherwise, the data is updated (depending on the parameters used during creation) and the recipient is created.\n\n- Customer\n    \n    - Signers (signatories directory)\n        \n    - Dossiers\n        \n        - Recipients (signatories who are recipients of the practice document)\n            \n        - Documents (`unsigned_document` or `signed_document`)\n            \n        - Emails (all emails sent to signatories)\n            \n        - SMS (all SMS messages sent)\n            \n\n# Workflow via API\n\nThe workflow can be managed by an external system through the APIs described in this documentation.  \nAccess to the UI may be required to modify certain configurations.  \nThese are the typical steps for creating a dossier:\n\n1. The customer (proposer) authenticates and obtains the token to include in the header for using the endpoints.\n    \n2. Calls the endpoint to create the dossier.\n    \n    1. Attaches the data for each signatory.\n        \n        - OTP Service adds or updates the signatory if it already exists.\n            \n        - Then it creates the recipient from the signatory's data.\n            \n    2. Attaches the file of the document to be signed and the list of signature points, which may have absolute or dynamic values.\n        \n        - OTP Service verifies that the document file is a valid PDF and has not been previously signed.\n            \n        - It also checks that the signature point data has correct coordinates, both in terms of form and integrity. For example, it verifies that the page number indicated for the signature point exists in the document (refer to the paragraph \"How to obtain signature point coordinates\" in the CREATE section).\n            \n    3. Optional settings can be specified (otherwise, the default settings defined in the UI will be used).\n        \n        - For sending the email with the document to be signed to all signatories. Usually, OTP Service handles this, but the _Proposer_ can choose to do it independently.\n            \n        - Token for external signature management. Essentially, this is a link that is generated and provided to the signatory instead of the one normally supplied by OTP Service, for cases where the _Proposer_ wishes to personally oversee the process, including the visual aspect, and rely on lower-level APIs for OTP sending and verification.\n            \n        - For the creation of the signed document, this too can be created by the _Proposer_ and uploaded via API (see the \"Dossiers/ADD DOCUMENT\" endpoint).\n            \n        - For sending the _signed_ document via email to all signatories.\n            \n3. The workflow continues to completion in various ways, depending on the options chosen by the _Proposer_ and described in the previous points.\n    \n\n# Callbacks (Webhooks)\n\nA callback is an asynchronous request that OTP Service performs in response to an event to update an external system.\n\nThe events that trigger a callback are updates to the status of the dossier and/or each individual recipient.  \nOTP Service makes a `PUT` request to an endpoint defined by the proposer. To set the endpoint URL, the admin UI must be used (the \"Status Change Callback URL\" field in the organization edit section), or OTP support can be contacted.\n\nTo associate the OTP Service dossier with their own system, the proposer can use two options (see Dossiers/CREATE for more information):\n\n1. Assign a custom reference using the following fields:\n    \n    - `customer_dossier_id`\n        \n    - `customer_contract_hash`\n        \n2. Use the UUID assigned directly by OTP Service\n    \n\nWhen the proposer creates the dossier, they can include their own identifier as a parameter, choosing between the two fields mentioned above. In any case, OTP service assigns a unique UUID to both the dossier and each recipient, which is provided in the response upon creation. If these are stored in the proposer's system, they can be used to associate callbacks with the dossier or with individual recipients.\n\nThis is an example of a URL that can be defined on your own system:\n\n`put 'documents/callback'`\n\nThe OTP service account will be configured by entering something like the following as the value for \"Status Change Callback URL\":\n\n`https://yourdomain.example.com/documents/callback`\n\nThe callback executed by OTP service will include the following parameters:\n\n- `callback_object` -> type of object (dossier or recipient)\n    \n- `callback_state` -> the status at the time the call is invoked\n    \n- `customer_dossier_id` -> the ID provided by the proposer upon dossier creation, if any\n    \n- `customer_contract_hash` -> the hash (or UUID) provided by the proposer upon dossier creation, if any\n    \n- `uuid` -> (only if the object is a dossier) the UUID automatically assigned by OTP Service upon dossier creation\n    \n- `dossier_uuid` -> (only if the object is a recipient) the dossier UUID\n    \n- `recipient_uuid` -> (only if the object is a recipient) the UUID of the recipient whose status has changed\n    \n\nThe `callback_state` variable indicates the status of the dossier at the moment the callback is scheduled. This differs from `state`, which indicates the current status. If the callback takes several seconds before being executed, the status may no longer match the one set (some statuses last only as long as the processing time, which can be very brief in some cases). This way, there is the option to choose, helping to avoid responses that may be difficult to manage.\n\nAdditionally, other parameters can be added based on the status or type of event (dossier status or recipient). For example, if a dossier has been signed, the process may also provide the URL of the signed document, the code for signature verification, etc.\n\n**Dossier or Recipient Callback**: For simplicity, the URL for the callback is unique, and the parameters make it possible to identify the object that triggered the event (dossier status change or recipient status change).\n\n- `callback_object` -> type of object (dossier or recipient)\n    \n\nTo activate a recipient's callback, it is necessary to add the parameter in the recipient object’s JSON during creation (see the CREATE section for more information).\n\nA callback triggered by a change to a final state will contain additional parameters that depend on the type of object.\n\n**Dossier**\n\n- `signed_document_url` -> The URL of the signed document (available starting from dossier state `signed_document_loaded`)\n    \n- `final_checksum` -> The final hash: \"Signature Verification Code.\"\n    \n\n**Recipient**\n\n- If of type \"AES,\" all personal data fields that may have been entered or modified by the signatory during the signing process will be added to the call parameters. This allows the proposer to keep their own system up to date.\n    \n\nThe details of the statuses are provided in the \"Process Status\" table following the examples below.\n\n**JSON Callback examples**\n\nExample of parameters included in a callback triggered by a dossier status change:\n\n``` json\n{\"callback_object\":\"dossier\", \"callback_state\":\"signed\", \"customer_contract_hash\":\"b085520f-abe1-48f3-9587-6568af775223\", \"customer_dossier_id\":123, \"uuid\":\"3becb0e1-bbde-4918-a6d0-3d8e68f2f31f\", \"final_checksum\":\"0ea13b45552f7955e02dc5c463e961cc\", \"signed_document_url\":\"https://otpservice.io/.../a_signed_document.pdf\"}\n\n ```\n\nExample of parameters included in a callback triggered by a recipient status change:\n\n``` json\n{\"callback_object\":\"recipient\",\"customer_contract_hash\":\"b085520f-abe1-48f3-9587-6568af775216\",\"customer_dossier_id\":1,\"dossier_uuid\":\"26dfcb08-5baa-467a-8062-d1e1ca1b1900\",\"recipient_uuid\":\"f15a18db-f174-4a3e-a6ad-022773c960d8\",\"dossier_current_state\":\"signed\",\"recipient_current_state\":\"signed\",\"recipient_callback_state\":\"signed\"}\n\n ```\n\n**Tentativi callbacks**: If the callback fails, it is retried three additional times with a delay calculated using the following formula:\n\n`(retry_count ** 4) + 15 + rand(30)`\n\nIn effect, the retries occur after:\n\n- Attempt 1 -> 16 seconds + a random number of seconds (from 0 to 30)\n    \n- Attempt 2 -> 31 seconds + a random number of seconds (from 0 to 30)\n    \n- Attempt 3 -> 96 seconds + a random number of seconds (from 0 to 30)\n    \n\n# Workflow Statuses\n\nThe names of the callbacks to use in the API calls are the lowercase snake_case versions of the names in the first two columns of the table below. For example: Draft becomes `draft` and Generating Signed Document becomes `generating_signed_document`\n\n| Dossier | Recipient | Description |\n| --- | --- | --- |\n| Draft | Just Created | The dossier begins as a draft from the UI to allow signature points to be created, or from the API if created with the `\"state\": \"draft\"` parameter.  <br>It can be modified or deleted. To send it to recipients, an UPDATE with the `\"end_draft\": true` parameter must be performed. |\n| Just Created | \" | This is the initial status if created by the API without `\"state\": \"draft\"`. In this state, it can no longer be modified, and the cost is charged at this point. |\n| Notified | Notifying | If the option is enabled, the document notification for each recipient in the dossier is processed. |\n| \" | Notified | The sending SMTP server confirms that the document has been sent. (NOTE: this is not a final status and can be revised in the event of errors.) |\n| \" | Notification Error | An error occurs after sending, such as an invalid address or a bounce from the recipient’s SMTP server. |\n| \" | Viewed | The signatory opens their link to the dossier. |\n| Signing | Accepting | When the first signatory accepts the first signature point, the dossier progresses to the signing stage. |\n| \" | Accepted | The signatory has accepted all signature points, and the dossier remains in the signing stage. |\n| \" | Validating | The signatory has submitted the OTP to validate acceptance. |\n| \" | Identifying | The signatory has verified the OTP and validated acceptance, and identification is in progress (FEA only). |\n| \" | Signed | The signatory has verified the OTP and validated acceptance (for FS and FEA, if the signatories are already identified). |\n| Signed | \" | When all signatories have signed, the dossier progresses. |\n| Generating Signed Document | \" | If the option is enabled, the signed PDF contract is generated. |\n| Signed Document Loaded | \" | Otherwise, it must be uploaded (designed for API use). |\n| Signed Document Sent | Sending Signed Document | If the option is enabled, the signed contract is sent to each signatory. A separate email is sent to each signatory, and this status indicates that preparation is underway. |\n| \" | Signed Document Sent | The sending SMTP server confirms that the document has been sent. (NOTE: this is not a final status and can be revised in the event of errors.) |\n| Completed | \" | After signing and sending the signed document to all, the dossier can be considered complete. |\n| \" | Signed Document Sending Error | An error occurs after sending, requiring a manual attempt for re-sending. |\n\nThe progression of statuses is automatic based on data and the dossier’s options, or it may await a specific manual action.  \nFor example: if the dossier is created with the \"Send document to be signed\" option, the recipient’s status will automatically progress to \"Notified\" and remain there until the signatory opens the document and begins the acceptance process, etc. If the option is not present (because the proposer has their own notification system), the status will stop at \"Just Created.\"\n\n# Callback example\n\nTo facilitate callback testing, we provide a simple Python 3 script that returns a 200 response for each received call and displays the request body on the screen. The server must be accessible via the internet. To handle HTTPS calls, it should be placed behind a reverse proxy that terminates the HTTPS connection before forwarding it.\n\n``` Python\nfrom http.server import BaseHTTPRequestHandler, HTTPServer\nclass SimpleHTTPRequestHandler(BaseHTTPRequestHandler):\n    def do_PUT(self):\n        return self.ok()\n    def do_POST(self):\n        return self.ok()\n    def ok(self):\n        print(self.rfile.read(int(self.headers.get('Content-Length', 0))).decode('utf-8'))\n        self.send_response(200)\n        self.send_header('Content-type', 'application/json')\n        self.end_headers()\n        self.wfile.write('{}'.encode('utf-8'))\nif __name__ == '__main__':\n    port = 9876\n    httpd = HTTPServer(('localhost', port), SimpleHTTPRequestHandler)\n    print(f'Starting httpd server on port {port}...')\n    httpd.serve_forever()\n\n ```\n\nTo verify its operation, assuming a reverse proxy on `server.example.com` terminates the HTTPS connection and redirects it to port 9876 on the same server.\n\ncurl -X POST [https://server.example.com/otpservice-callbacks](https://server.example.com/otpservice-callbacks) \\\\\n\n```\n  --data-raw '{\"Hello\":\"World\"}'\n\n ```\n\n# Changelog\n\n_2024-11-30_\n\nDocument how to keep a dossier in state `just_created` upon creation and send it later with a PUT (Update).\n\n_2024-07-29_\n\nAdded signature point permissions. Removed the external/internal groups for recipients and signature points.\n\n_2023-12-05_  \nAdded the ability to request an additional OTP resend via SMS or email.","schema":"https://schema.getpostman.com/json/collection/v2.0.0/collection.json","isPublicCollection":false,"owner":"189424","team":5903,"collectionId":"18819512-a78c-40a4-8507-3c10ac07127a","publishedId":"2sAXxQdrbp","public":true,"publicUrl":"https://documenter-api.postman.tech/view/189424/2sAXxQdrbp","privateUrl":"https://go.postman.co/documentation/189424-18819512-a78c-40a4-8507-3c10ac07127a","customColor":{"top-bar":"FFFFFF","right-sidebar":"303030","highlight":"FF6C37"},"documentationLayout":"classic-double-column","customisation":{"metaTags":[{"name":"description","value":""},{"name":"title","value":""}],"appearance":{"default":"light","themes":[{"name":"dark","logo":null,"colors":{"top-bar":"212121","right-sidebar":"303030","highlight":"FF6C37"}},{"name":"light","logo":null,"colors":{"top-bar":"FFFFFF","right-sidebar":"303030","highlight":"FF6C37"}}]}},"version":"8.10.1","publishDate":"2024-10-16T12:00:06.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/5d6dac62cf90c6287a34e1cfb20d4e3aad5e757ce453addfde564f0828a84c77","favicon":""},"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://documenter.gw.postman.com/view/metadata/2sAXxQdrbp"}