Skip to navigation
API referenceStatus and Managing Function Group

Rules for CorrectAndResendEnvelope

View as Markdown

API user specific rules

  • The length of any of the email addresses (specified as CorrectedEmail) must not exceed 100 characters. Else, the XML validation fails and the processor throws a Validation error.

  • The email addresses (specified as CorrectedEmail) must conform to the appropriate email format. Else, the XML validation fails and the processor throws a Validation error.

  • The length of any of the EnvelopeID must not exceed 100 characters. Else, the XML validation fails and the processor throws a Validation error.

  • If the CorrectedAccessCode field is not null and not empty then regardless of whether the value of CorrectedAccessCodeRequired is ‘true’ or ‘false’ the CorrectedAccessCode is considered as the new Access Code for the specified recipient.

  • If the CorrectedAccessCode field is null or empty:

  • If the value of CorrectedAccessCodeRequired is ‘false’, the existing Access Code for the specified recipient is cancelled.

    • If the CorrectedAccessCodeRequired is ‘true’ then the existing access code is left as it is.

Rules for Exceptions thrown by the API

  • An envelope having the specified EnvelopeID must exist in the system. Else, an exception with the error message “Envelope_Does_Not_Exist” is thrown.
  • The status of the envelope with the specified EnvelopeID must be ‘Sent’ or ‘Delivered’. Else, an exception with the error message “Envelope_Cannot_Correct_Invalid_State” is thrown.
  • The user making the API calls must have permissions to correct the Envelope. Else, an exception with the error message “User_Lacks_Permissions” is thrown. The API user can correct the Envelope only if the user is the sender of the envelope.
  • User specified by PreviousUserName and PreviousEmail should be the owner of the envelope. Else an exception with error message “User_Not_Envelope_Sender” is thrown.
  • The envelope with the specified EnvelopeID must not have duplicate recipients. Else an exception is thrown with the error message “Envelope_Has_Duplicate_Recipients”. An envelope with duplicate recipients cannot be corrected, because if a correction is specified for a user who exists as more than one recipient, then it raises an ambiguity on which instance of the user to be corrected.
  • More than one correction must not be specified for a given recipient as it raises an ambiguity on which correction to apply. Else, an exception with the error message “Correction_Has_Duplicate_Recipients” thrown.
  • The CorrectedUserName of any correction (after trimming of leading and following spaces) must not be empty. Else an exception with the error message “Correction_Has_A_Blank_Username” is thrown.
  • The final set of recipients of the envelope (assuming that the corrections that succeed are applied) must not contain duplicates. Else an exception is thrown with the error message “Correction_Results_In_Duplicate_Recipients”.
  • Recipient specified by CorrectedUserName and CorrectedEmail should exist else exception with error message “Recipient_Not_Found_For_Correction” is thrown.
  • Correcting Carbon copy recipient is not allowed. If tried the exception with error message “Captive_Carbon_Copy_Recipient_Not_Supported” will be thrown.
  • If the corrected Email specified has already been reserved by some other account then an exception with error message “Corrected_Email_Is_Reserved” is thrown.

Rules for return value of the API

  • The status of a recipient (for whom a correction is specified) must not be ‘Signed’, ‘Declined’ or ‘Completed’. Else, correction is not permitted for this recipient and CorrectionSucceeded value is set to ‘false’. In other words a CorrectionSucceeded value of ‘false’ indicates that the correction could not be applied, as the status of the recipient does not permit corrections.
  • The RecipientCorrection object in the CorrectAndResendEnvelope the same as the RecipientCorrection passed as the argument to the API.