FAQ

  1. Are there any fees associated with using the Case APIs?
    There are NO fees associated with using the Case APIs. The Case API is available to customers who have an active Juniper Care or partner equivalent support contract.

  2. When did Juniper release the CaseAPIs?
    Juniper released the CaseAPIs on Nov 24th, 2019.

  3. Does Juniper provide a sandbox environment enabling clients to do development and testing without having to go thru an Onboarding process?
    Juniper does NOT provide a true sandbox environment. Juniper does provide a Non Production Testing environment for interested clients which requires submitting the Client Questionnaire that would then initiate an Onboarding Process.

  4. Can case/SR (service request) created via Juniper Selfservice portals such as my.juniper.net or casemanager.juniper.net be updated via the API Channel?
    Yes, as long as the Account ID associated with the SR is participating in the API channel (i.e. is an Account ID specified during the Onboarding process) the SR can be updated via the API channel if all the required attributes are specified in the updateSR API request.

  5. Do all cases/SRs created via the API channel need to be created with the same user?
    No, not all and is in fact NOT recommended. On the API requests, the requirement for the mandatory keys - contactEmail and accountID is as shown below called out in the JSON Key specification table. It is expected to be the person actually opening the ticket on your support CRM system or updating an existing ticket on your support CRM system. Juniper Support engineers expect this to be a real person and not an alias.

    JSON Key Data Type Length Description Mandatory or Optional Comments
    accountID CHAR 10 Account ID Mandatory On createSRAPI request, the contactEmail must be associated with this accountID. This new SR is associated with this accountID.
    In all other API requests, the contactEmail must be associated with this accountID and must match the accountID in the serviceRequestNumber.
    contactEmail CHAR 241 Contact E-Mail Address Mandatory This is a registered user of the Client in our Juniper Customer Service Portal.
    This user must be associated with the accountID.
    It is expected to be different from the userId and represent the person actually opening the ticket on your support CRM system or updating an existing ticket on your support CRM system.
    In createSR API requests, this is the SR Reporter on the SR created on the Juniper Support system. Juniper Support engineers expect this to be a real person and not an alias.
    In updateSR API requests this is recorded as the person making the update.

  6. What is the difference between userId and contactEmail in the API request payload specification?
    All of the JSON key details are called out in the JSON Key specification table. userid, contactEmail and accountID specifications in particular are as shown below.

    JSON Key Data Type Length Description Mandatory or Optional Comments
    accountID CHAR 10 Account ID Mandatory On createSRAPI request, the contactEmail must be associated with this accountID. This new SR is associated with this accountID.
    In all other API requests, the contactEmail must be associated with this accountID and must match the accountID in the serviceRequestNumber.
    contactEmail CHAR 241 Contact E-Mail Address Mandatory This is a registered user of the Client in our Juniper Customer Service Portal.
    This user must be associated with the accountID.
    It is expected to be different from the userId and represent the person actually opening the ticket on your support CRM system or updating an existing ticket on your support CRM system.
    In createSR API requests, this is the SR Reporter on the SR created on the Juniper Support system. Juniper Support engineers expect this to be a real person and not an alias.
    In updateSR API requests this is recorded as the person making the update.
    userId CHAR 241 Registered userid Mandatory The userId is a mandatory key on each of the 10 SR API requests.
    It must be a registered user on Juniper’s Customer Service Portal.
    It must match that provided during Client onboarding.

  7. Will updates that occur on SRs created via Juniper Selfservice portals such as my.juniper.net or casemanager.juniper.net result in a publishSR to be generated?
    Yes, if the following requirements are met: If the Account ID associated with the SR created via Juniper Selfservice portals is participating in the API channel AND has a Non Null Customer Tracking Number a publishSR will be sent. If the Account ID associated with the SR is participating in the API channel but does not have a Customer Tracking Number specified, the publishSR is not sent to the endpoint.

  8. Does publishSR message sent to endpoint contain only what has changed from previous one sent or is it always the complete srDetails?
    The content of the publishSR is not going to tell you what has changed. Each publishSR sent is always the complete srDetails with the latest values associated with the various attributes. You need to write code to determine the delta.

    For example, let’s look at notes array:

    publish that you received at time T1 say contained this:
    
    "notes": [
        {
          "dateTime": "2019-08-15T21:11:19.000Z",
          "description": "Current Status",
          "id": "005056A34D531EE8B5C9E50B27BC7CE0-20190815211122310-ZSTS",
          "originator": "Venkat Bellamkonda",
          "title": ""
        },
        {
          "dateTime": "2019-08-15T21:10:17.000Z",
          "description": "Resolution Notes",
          "id": "005056A34D531EE8B5C9E50B27BC7CE0--Z014",
          "originator": "Venkat Bellamkonda",
          "title": ""
        },
        {
          "dateTime": "2019-08-15T18:47:08.000Z",
          "description": "Customer Notes",
          "id": "005056A34D531EE8B5C9E50B27BC7CE0-20190815184709078-Z011",
          "originator": "Venkat Bellamkonda",
          "title": ""
        }
    ]
    

    Then at time T2 let’s say you received the below. You have to figure out that the first two items of the notes array are additional ones since the previous publish based on the timestamp of the latest note received at T1. Then for those note ids, if they are in the most recentNotes array (latest five will be included in the recentNotes array) then you have the content already for those is the publishSR received at T2 else you have to use queryNote to retrieve the note content associated with the new note ids determined.
    
    "notes": [
        {
          "dateTime": "2019-08-15T21:57:28.000Z",
          "description": "Customer Notes",
          "id": "005056A34D531EE8B5C9E50B27BC7CE0-20190815215729686-Z011",
          "originator": "Venkat Bellamkonda",
          "title": ""
        },
    
        {
          "dateTime": "2019-08-15T22:00:00.000Z",
          "description": "Current Status",
          "id": "005056A34D531EE8B5C9E50B27BC7CE0-20190815215729686-Z011",
          "originator": "Venkat Bellamkonda",
          "title": ""
        },
        {
          "dateTime": "2019-08-15T21:11:19.000Z",
          "description": "Current Status",
          "id": "005056A34D531EE8B5C9E50B27BC7CE0-20190815211122310-ZSTS",
          "originator": "Venkat Bellamkonda",
          "title": ""
        },
        {
          "dateTime": "2019-08-15T21:10:17.000Z",
          "description": "Resolution Notes",
          "id": "005056A34D531EE8B5C9E50B27BC7CE0--Z014",
          "originator": "Venkat Bellamkonda",
          "title": ""
        },
        {
          "dateTime": "2019-08-15T18:47:08.000Z",
          "description": "Customer Notes",
          "id": "005056A34D531EE8B5C9E50B27BC7CE0-20190815184709078-Z011",
          "originator": "Venkat Bellamkonda",
          "title": ""
        }
    ]
    
    For other SR data blocks such as attachedFiles, linkedReferences, rmas etc. you need to figure out what is best to do – blindly overwrite your case record instance for the said data with what is provided in the received publish or figure out delta and do needful update. From a database point of view, data merge construct can be used. You should expect scenario (though it might not be that often) where for example in linkedReferences an item got removed because JTAC engineer linked a reference then later on realized that it is not a good reference and removed a reference.

    On single valued attributes such as for example: srStatus, priority, followupmethod, ccEmail etc. the current value is provided in the publishSR and you are expected to update your case record. A change history of these single valued attributes are NOT provided in publishSR.

  9. Can a publishSR message reflect multiple changes to the case/SR?
    Yes, there can be scenarios where one publishSR message can have multiple changes with respect to the previous publishSR message sent. For example, let’s say JTAC engineer links a PR or KB article to the case; adds a note to the case and changes the status of the case to ‘Open - Awaiting Customer Input’ and does ONE save operation. Our system permits the JTAC engineer to do that. Then in this scenario the resulting publishSR will reflect multiple changes – the linkedReference array will have a new item, the notes array will have a new item and recentNotes array will have the latest 5 notes, the srStatus attribute will reflect the latest status.

  10. What happens to the publish process if Juniper is not able to connect to Client endpoint?
    Three attempts are made to connect to the endpoint in a span of about two minutes. If still unsuccessful then an EMAIL is sent to the email address provided during onboarding process for this particular purpose. Example from our Non Production environment shown below. The email will also contain the publish payload as an attachment.


  11. Can updates be made to cases/SRs that are closed on Juniper system?
    No. updateSR API request on closed SRs will receive a synchronous response with http code of 400 with the response payload containing a fault array with error 782.
    
    {
        "updateSRResponse": {
            "status": "Error",
            "statusCode": "400",
            "message": "Error in processing the request",
            "responseDateTime": "2019-12-30T18:20:57.469Z",
            "serviceRequestNumber": "2019-1207-0121",
            "customerCaseNumber": null,
            "customerUniqueTransactionID": "omx9zixsjuidpl2c4hocuzk22vndtgz3rutk7610",
            "fault": [
                {
                    "errorClass": "Validation",
                    "errorType": "Error",
                    "errorCode": "782",
                    "errorMessage": "serviceRequestNumber - 2019-1207-0121 - is already closed. No updates allowed."
                }
            ]
        }
    }
    

  12. How does Juniper ensure that duplicate cases/SRs are not created? (Understanding error 955, warning 758, error 785)
    The design has ensured that duplicate cases/SRs are prevented from being created.
    • Each API request payload requires a mandatory key customerUniqueTransactionID. This key must have a unique value on each request irrespective of the response to the request being either a success or error. This ensures that if client application has a defect or for some reason gets into a scenario of sending the same API request multiple times they are rejected with a error response.
      
      {
          "createSRResponse": {
              "status": "Error",
              "statusCode": "400",
              "message": "Error in processing the request",
              "responseDateTime": "2019-12-31T22:58:00.701Z",
              "serviceRequestNumber": null,
              "customerCaseNumber": "PP-20191231",
              "customerUniqueTransactionID": "transid-20191231",
              "fault": [
                  {
                      "errorClass": "Validation",
                      "errorType": "Error",
                      "errorCode": "955",
                      "errorMessage": "Duplicate customerUniqueTransactionID detected. Please provide an unique transaction ID."
                  }
              ]
          }
      }
      

    • If client sends a createSR request with a customerCaseNumber that has already been used i.e. an SR already exists for the accountID specified then the expected behavior is as follows.


      • If the existing SR is in Open status then the createSR request is converted to an updateSR request and processed. Additionally an asynchronous warning is sent via publishSR as shown below.
        
        First createSR request will receive a synchronous success response upon passing all validation checks.
        {
            "createSRResponse": {
                "status": "Success",
                "statusCode": "200",
                "message": "Successfully processed the request",
                "responseDateTime": "2019-11-02T16:57:47.039Z",
                "serviceRequestNumber": null,
                "customerCaseNumber": "PP-crsr-20191024-874729",
                "customerUniqueTransactionID": "1p43aqeboziyk7tdrrshfrh2nkcchku2rfo0xaph"
            }
        }
        
        Subsequently an asynchronous publishSR is sent with warning 758
        {
          "srDetails": {
            "appId": "9nCHF5W6emhIyWQ1BRoAJXHNvOIcHBIAosDkde80",
            "customerCaseNumber": "PP-crsr-20191024-874729",
            "serviceRequestNumber": null,
            "customerSourceID": "pristineparts-partner",
            "customerUniqueTransactionID": "1p43aqeboziyk7tdrrshfrh2nkcchku2rfo0xaph",
            "junUniqueTransactionID": "1p43aqeboziyk7tdrrshfrh2nkcchku2rfo0xaph",
            "transactionDateTime": "2019-11-02T16:57:50.846Z",
            "status": "Warning",
            "statusCode": "300",
            "message": "Successfully processed the request but there are warnings that need to be looked at.",
            "fault": [
              {
                "errorClass": "Processing",
                "errorType": "Warning",
                "errorCode": "758",
                "errorMessage": "Service Request - 2019-1102-T-3249 - is already created for this customerCaseNumber - PP-crsr-20191024FBSn-874729. Since it is open the create request has been treated as an update request and SR - 2019-1102-T-3249 - updated accordingly."
              }
            ]
          }
        }
        

      • If the existing SR is in Closed status then an asynchronous Error is sent via publishSR as shown below.
        
        {
          "srDetails": {
            "appId": "9nCHF5W6emhIyWQ1BRoAJXHNvOIcHBIAosDkde80",
            "customerCaseNumber": "(Ref:IN:00097791)",
            "serviceRequestNumber": null,
            "customerSourceID": "pristineparts-partner",
            "customerUniqueTransactionID": "qycdfcp2qk1xv1udhqjbtv9pwng01992mul5x5rn",
            "junUniqueTransactionID": "qycdfcp2qk1xv1udhqjbtv9pwng01992mul5x5rn",
            "transactionDateTime": "2019-09-30T01:59:14.884Z",
            "srStatus": null,
            "status": "Error",
            "statusCode": "400",
            "message": "Error in processing the request",
            "fault": [
              {
                "errorClass": "Processing",
                "errorType": "Error",
                "errorCode": "785",
                "errorMessage": "serviceRequestNumber - 2018-0704-T-0484 - already exists for the provided customerCaseNumber - (Ref:IN:00097791) - which is in Closed Status. Resubmit create sr request with a new customerCaseNumber."
              }
            ]
          }
        }
        

  13. What features or functionality are NOT supported via the API channel in comparison to Juniper's Casemanagement Selfservice portals?
    With the design goal of the 10 Case APIs provided via the API channel being for a B2B integration between a Clients Ticketing System application and Juniper's Support CRM system, the following functionality is NOT supported via the API channel.
    • Get kind of queries such as 'list of P1 cases created against certain accountID' or 'current list of all open cases' are NOT supported via the API Channel. These are expected to be determined by the Client from their own ticketing system.
    • Automatic Warranty RMA creation is NOT supported via API Channel. On CreateSR request for Tech SRs, if the SN provided is entitled only for a Warranty RMA, an SR is not created and an error response is sent with an errorCode of 609 'Entitlement Check Failed: Serial Number &1 has only Active Warranty. Please open Technical SR via other channels for warranty support'.
    • REQUEST A CALL feature provided in my.juniper.net self service portal is NOT supported via API Channel.
    • Attaching Files via RESTRICTED-UPLOAD method, which is provided primarily for US DOD Customers and US DOD Partners, is NOT supported via API Channel.

  14. Are there any rate limits defined?
    Yes, Rate Limit is imposed. Rate Limit is defined as the maximum number of Case API requests that can be submitted per hour. Each client will be permitted a maximum of 300 requests/hour. Upon receipt of a request the rate of requests is calculated and if it exceeds 300 requests/hour the request will not be processed and a rate limit exceeded error is sent.

  15. Does Juniper plan to provide an API to request an RMA to be created without JTAC engineer involvement?
    At this time Juniper does NOT plan to provide an API to automatically request for an RMA to be created without a JTAC engineer engagement. This is similar to such a capability NOT supported via the self service portals.

  16. What is effort involved in integrating with Juniper CaseAPIs?
    Quantification of effort depends on your approach. Juniper can only provide guidance as follows:

    We believe the architecture/model of our CaseAPIs to be robust, secure and provides for an efficient B2B integration. Additionally we have made available comprehensive documentation providing a detailed overview (including a webinar style video), laying out the onboarding process, providing the API specification in an easy to understand and well formatted layout, a full set of examples, a basic reference client and this FAQ. Spending the time to review the information provided will certainly help make the integration effort quicker.

    For the most expedient integration our recommendation is the developer assigned understands what a Juniper Case and RMA really is. We suggest the developer works with a person in your organization familiar with Juniper Case management Selfservice Webportal (my.juniper.net or casemanager.juniper.net) and walks thru the lifecycle of a case from creation of case to updating the case, attaching files to the case and requesting case to be closed.

    This should result in the developer (who typically we have seen has never created a Juniper case using our selfservice portals) quickly understand the difference between Admin and Tech cases, the entitlement enforcement on Tech Cases and the construct of linked references, files attached, RMA and notes. This effort which should not take more than 30 mins will result in the developer in quickly understanding the request API payload definition and what the various keys are and why we have them. This initial investment thirty minute investment will definitely result in lesser effort during the development/test cycle.