Difference between revisions of "Sending a Direct Message"

From Updox API
Jump to: navigation, search
Line 1: Line 1:
 
This topic covers how to send a direct message from one address to another trusted direct address.  For additional information regarding what direct messaging is, please review [https://updoxqa.com/wiki/index.php?title=Direct_Messaging this topic].
 
This topic covers how to send a direct message from one address to another trusted direct address.  For additional information regarding what direct messaging is, please review [https://updoxqa.com/wiki/index.php?title=Direct_Messaging this topic].
  
Set up practice
+
 
 +
== Set up practice ==
 +
 
 
General instructions can be found [https://updoxqa.com/wiki/index.php?title=Account_Management here] on how to create a practice, but the critical component to specify in the API request when setting up a practice that will want to communicate via direct messages is the '''directDomain'''.  Submitting a single string value results in that name being prepended to the root direct domain value as a subdomain.  For partners utilizing the domain bound certificate type, each account/practice should have their own unique subdomain value.  After submitting, the '''PracticeList''' API can be called and the full domain is viewable in the response for each account.
 
General instructions can be found [https://updoxqa.com/wiki/index.php?title=Account_Management here] on how to create a practice, but the critical component to specify in the API request when setting up a practice that will want to communicate via direct messages is the '''directDomain'''.  Submitting a single string value results in that name being prepended to the root direct domain value as a subdomain.  For partners utilizing the domain bound certificate type, each account/practice should have their own unique subdomain value.  After submitting, the '''PracticeList''' API can be called and the full domain is viewable in the response for each account.
  
Set up user
+
 
 +
== Set up user ==
 +
 
 
Instructions outlined [https://updoxqa.com/wiki/index.php?title=DirectTrust_Activation here] outline the general process for establishing a user.  The critical part of this for direct communication is the directAddress value sent in the request.  This is the local part of the direct email address and gets prepended to the left of the @.
 
Instructions outlined [https://updoxqa.com/wiki/index.php?title=DirectTrust_Activation here] outline the general process for establishing a user.  The critical part of this for direct communication is the directAddress value sent in the request.  This is the local part of the direct email address and gets prepended to the left of the @.
  
  
Identity Verification
+
 
At this point, in a production environment, the user is ready to go through the self service identity verification process.
+
== Identity Verification ==
 +
 
 +
At this point, if the previous steps of setting up a practice and user are in place, the user is able to access the self service identity verification user interface.  Additional information regarding this can be found [https://updoxqa.com/wiki/index.php?title=DirectTrust_Activation here].  Again, if you are in a testing environment this is not necessary.  However, if it is still desired to do so, this can be accomplished by completing the process using one of the testcases provided [https://updoxqa.com/wiki/index.php?title=DirectTrust_Activation_Test_Cases here].
  
  

Revision as of 15:03, 12 May 2016

This topic covers how to send a direct message from one address to another trusted direct address. For additional information regarding what direct messaging is, please review this topic.


Set up practice

General instructions can be found here on how to create a practice, but the critical component to specify in the API request when setting up a practice that will want to communicate via direct messages is the directDomain. Submitting a single string value results in that name being prepended to the root direct domain value as a subdomain. For partners utilizing the domain bound certificate type, each account/practice should have their own unique subdomain value. After submitting, the PracticeList API can be called and the full domain is viewable in the response for each account.


Set up user

Instructions outlined here outline the general process for establishing a user. The critical part of this for direct communication is the directAddress value sent in the request. This is the local part of the direct email address and gets prepended to the left of the @.


Identity Verification

At this point, if the previous steps of setting up a practice and user are in place, the user is able to access the self service identity verification user interface. Additional information regarding this can be found here. Again, if you are in a testing environment this is not necessary. However, if it is still desired to do so, this can be accomplished by completing the process using one of the testcases provided here.


Obtain Direct recipient

Call API to validate address is trusted

Call API to send direct message