Create a shared file request

Opens a request for a file to be uploaded, against an existing SharedFileRequestConfiguration. The title, instructions, accepted MIME types and context type come from that configuration.

The body names a relationship, not the two accounts: payerPayeeId carries both seats, and the caller must hold one of them. One shape serves two callers. A PAYER orders a document directly, naming configurationId; no requirement is needed to justify it. A PAYEE opens their own request against a requirement that asks for a document, naming requirementId and leaving configurationId, externalId and metadata unset — the platform supplies the configuration that the cited requirement authorizes, so the payee cannot choose it, and the other two are the payer's to set.

A relationship that does not resolve, or one the caller holds no seat on, returns 404 — the same answer either way, so a caller cannot learn which relationships exist.

The payee's two refusals are ordered, and the order is worth knowing before treating 400 as fatal. A payee MUST send requirementId; without it the answer is 400 regardless of what else the body carries, including the payer-only fields. With it, a payee who also sends configurationId, externalId or a non-empty metadata gets 422 for that field. So a payee body copied from the payer example answers 400 first — drop the payer-only fields AND add requirementId, rather than reading the 400 as malformed and giving up.

A repeat is bounded rather than duplicated, but only where a duplicate could strand something. When the body cites a requirementId and no externalId, a second create against the same relationship and configuration returns the request already outstanding instead of opening another, and the repeat's metadata is not merged onto it. A payer's direct-order create cites no requirement, binds nothing and so is never deduplicated — a second order is a second request.

Supplying an externalId already in use for this payer account returns 409 ResourceConflict — create is not an upsert, and naming one opts out of the deduplication above. Recover by listing with ?filter[externalId][eq]= to retrieve the existing request.

Recent Requests
Log in to see full request history
TimeStatusUser Agent
Retrieving recent requests…
LoadingLoading…
Body Params

Open a request against an existing SharedFileRequestConfiguration. The title, instructions, acceptedMimeTypes and contextType come from that configuration and are not restated here: one configuration backs many requests, which is how a DocumentUpload requirement definition fans one template out across its payees.

The relationship named by payerPayeeId carries both account seats, so the caller names neither. One body serves two callers: a payer ordering a document directly, and a payee opening their own request against a requirement that asks for one.

string
required

The payer-payee relationship this request is opened in. Both account seats are resolved from it, and the caller must hold one of them — 404 otherwise, so a caller cannot learn which relationships exist.

Accepts canonical Wingspan ids and legacy composite relationship ids returned by V3 payer/payee read/list endpoints.

string

The requirement this request satisfies, and what authorizes the create.

Required from the payee seat; 400 without it. Optional from the payer seat, whose direct-order path needs no requirement to justify it. The id is a gate rather than a binding: it is discarded once the create is authorized and is never stored on the request.

string

The SharedFileRequestConfiguration this request is opened against. Must be owned by the relationship's payer account; 404 otherwise.

Payer seat only — 422 from the payee seat when a requirementId is present, because the configuration comes from the cited requirement rather than from the caller. A payee who sends no requirementId gets 400 for that instead, whatever else the body carries. A payer who sends this alongside requirementId has it overridden rather than refused: the authorized configuration wins.

string

Caller-supplied reconciliation id, unique per payer account. A duplicate returns 409 ResourceConflict.

Payer seat only — the namespace is the payer's, so 422 from the payee seat when a requirementId is present. A payee who sends no requirementId gets 400 for that first.

metadata
object

Caller annotations stored on the request.

Payer seat only, like externalId — this is one payer-owned bag and only the payer can edit it afterwards, so a non-empty value from the payee gets 422 when a requirementId is present, and 400 for the missing requirementId when it is not. An omitted or empty value is accepted from either seat.

Headers
string
length between 1 and 255
^[\x21-\x7e]{1,255}$

Optional idempotency token for authenticated POST and PATCH requests. Reusing the same key and body returns the cached response for 24 hours, except credential operations that explicitly document a 409 because one-time secret material is never cached; reusing it with a different body returns 409 IdempotencyKeyConflict. Use 1-255 printable ASCII characters.

string
^(?:[A-Za-z0-9_.]{22}|[a-f0-9]{24})$

Select the Account for an Account-scoped operation. A direct ServiceAccount API key MUST supply this header, and the target must be within the ServiceAccount owner's or Authorization grant's Account boundary. A Person bearer may select an Account on which it has an active Stakeholder, and an Account session may select its bound Account (or a descendant only when the session explicitly includes descendants).

string
enum
Defaults to application/json

Generated from available response content types

Allowed:
Responses

Language
Credentials
Bearer
JWT
LoadingLoading…
Response
Click Try It! to start a request and see the response here! Or choose an example:
application/json
application/problem+json