Opens a signature request against an existing DocumentTemplate. The title and signer roles come from that template.
Either party may call this. You name the RELATIONSHIP you are acting in (payerPayeeId) and never an account, and both account seats are resolved from it. A payer needs no requirement and may name a template directly.
The two payee rules are checked IN ORDER, which decides the status you get. A payee must send requirementId; without it the answer is 400 whatever else the body carries. With it, a payee who also sends templateId, externalId or metadata gets 422. So a 400 here means the requirement is missing — not that the rest of the body is malformed — and retrying with a requirementId is the fix.
A create that cites a requirementId is deduplicated: a repeat for the same relationship and template while an earlier request is still outstanding returns that request rather than opening a second one, so a payee's retry is safe. Three things opt out and open a NEW request — a payer's direct order (no requirementId), an externalId, and a payer reset of the requirement behind it.
Supplying an externalId already in use for this payer account returns 409 ResourceConflict — create is not an upsert. Recover by listing with ?filter[externalId][eq]= to retrieve the existing request. An externalId also opts the request out of the deduplication above, and is rejected outright from the payee seat.
This opens the request; it does not send it for signature. The payee calls POST /compliance/signature-requests/{requestId}/start next to mint the document and receive signing URLs.
| Time | Status | User Agent | |
|---|---|---|---|
Retrieving recent requests… | |||