Embedded request - requester_email_address can be a mail that not relate to a user?

Welcome to our forum, Amit Mor! Thanks for your post.

Can you clarify what you mean when saying you’d like your signature request to be embedded in your website, and that each request should have a different email address under the same company? 

How do you feel this would help with your current workflow?

Let me know once you have more details.

I'm using the following request: "/unclaimed_draft/create_embedded" to create a claim embedded URL in my application so my users can open the embedded view of Dropbox/sign to place the signature they want to request on the document they choose.
I want to let the user's email who requests the signature from his client appear in the Dropbox email to the signer, without this user having a Dropbox account.
Now I'm getting warnning:

{

"warning_msg": "No account found for <user_email>, 'requester_email_address' parameter value will be ignored. Using <email_of_my_admin_user> as requester email address",

"warning_name": "parameter_ignored"

}

Thanks for clarifying that! I’ve gone ahead and moved your request to the API section of our forum; our dedicated team can take a look and further assist.

Ok thanks

Hi,
can anyone help me with that?

Hi Amit,

Thanks for reaching out, the warning you’re seeing is expected behavior based on how the `requester_email_address` parameter works.

The `requester_email_address` lets you override the account email address so that notifications and the audit trail show a different requester email. However, in order for that email address to be accepted, it must meet all of the following requirements:

1. `test_mode` must be set to false
2. The email address must belong to an active Dropbox Sign account.
3. That Dropbox Sign account must be part of the same subscription/team as the account sending the request.
   
   

If any of these conditions aren’t met, the system will ignore the `requester_email_address` you send and instead use sending account's email and prompt a warning message like the one you received. 

In your case, since the user making the request does not have a Dropbox Sign account, the parameter can’t be applied.

As a possible workaround, we recommend using a generic account email (e.g., signatures@yourcompany.com) and adding the requester’s details in the `subject` or `message` parameters to appear in the email notifications for the request. This way, signers see who initiated the request, while all signature requests still come from your team’s authorized account. You can update the Dropbox Sign account email at any time following this article.

Please note that the email address used as the requester (either the account sending the request or one set with the `requester_email_address` parameter) will also be shown on the signature request’s audit trail.

Aside from that, any team member email addresses you would like to use in the `requester_email_address` parameter would need to have their own account set-up and be added to your Dropbox Sign team.

I'm sorry for any inconvenience this causes. Please let me know if you have any additional questions.