Documents

Metadata only, newest first. Fetch a single document to get a download URL - minting one per row here would issue links nobody follows.

Send the file as multipart/form-data in a file field, or as JSON with content_base64. BrokerPlus stores the file, classifies it, and checks it, the same as a file a broker uploads. The document starts with classification_status pending. The upload fires the document.uploaded webhook.

Every document that BrokerPlus asked a client for on this deal and that the client has not sent, one row for each applicant who owes it. Newest request first.

Requests documents from the client now, as the Request Documents window in BrokerPlus does. The documents are added to the client's portal, and each applicant that a document is for gets an email with their link. The response is 201 with the document requests that this call added. To ask for the documents on a request template, send its template_id: each document goes to the applicants the template names. The deal must have a client portal: the client must have sent their intake back. A key with the no_sending limit cannot do this. Supports Idempotency-Key: a retry with the same key gets the first response and emails nobody again.

The lender's funding documents that the broker is preparing on this deal: each document, the person who signs it, and its form fields with the values that BrokerPlus writes in. Only the open package (draft) is returned. To send it for signature, use POST /v1/deals/{id}/funding-package/send.

Every value that BrokerPlus holds on this deal and can write into a funding form: borrowers, the lawyer, the broker, and the reviewed commitment terms. Use a key as a field's source_key.

Adds documents that are already on the deal to its open funding package, and starts a package if there is none. BrokerPlus reads the form fields of each PDF as it is added. A document already in the package is not added again, so a retry is safe.

Stores the lender's forms on the deal and adds them to its open funding package, in one request. Send the files as multipart/form-data in files fields, or as JSON with content_base64. The documents are filed as lender funding forms and are not classified.

Names each form field of the document, decides who fills it, and proposes its value from the deal, as the Map button does in BrokerPlus. Values come from GET /v1/deals/{id}/funding-package/context and are never made up. The item becomes mapped, and this replaces the fields it had, including any edits. Check the fields and send state: reviewed before the broker sends the package.

Takes the document out of the package. The document stays on the deal.

Sets who signs the document, its order, its fields, or its state. fields replaces the whole list.

Sends the funding package for signature now, the same as Send on the deal's Funding tab. BrokerPlus fills each form and puts them in one signing envelope. The signing service emails each person once for the forms that are theirs. Every document must be reviewed with a signer who has an email. The response is 201 with the new signing envelope. A key with the no_sending limit cannot do this.

Each envelope that went out for signature on this deal, with its documents, the people it went to, and where the signing stands. Newest first.

One envelope that went out for signature on this deal.

The branded letter templates that the broker your key acts as can use: their own, and the ones their teams share. Sorted by name.

The letters made from templates for this deal, newest first.

Makes a branded letter from a template, with the deal's details filled in, as Generate on the deal does in BrokerPlus. When nothing needs the broker, BrokerPlus makes the PDF and files it on the deal: status is final and document_id is the file. Otherwise status is draft, and issues says what the broker must fix in BrokerPlus. Nothing is sent to anybody. Supports Idempotency-Key.

One letter made from a template. When status is final, download the PDF with GET /v1/documents/{document_id}.

Emails the letter's PDF as an attachment now, from the broker's connected mailbox. BrokerPlus sends it through a draft in the broker's name, so it is in their drafts folder and in Sent. The response is 201 with that draft, with status sent. A key with the no_sending limit gets 403. Supports Idempotency-Key.

The deal's signing package: each document a person on the deal signs, with where its signing is. Oldest first.

Adds one of the brokerage's saved documents, or each saved document with a form to sign in a preset, to the deal for the person who signs it. Returns 201 with the documents that are on the deal for that person. A document already on the deal for them is returned, not added again. Adding a document sends nothing.

One document in the deal's signing package, with where its signing is.

The saved sets of documents a broker can apply to this deal at once: the deal's team's and the brokerage's, for the deal's province or for every province.

Fills in the document as it would go out now and returns the PDF. Runs the same checks as a send: a document that cannot be sent returns 422 with the reason. Sends nothing and keeps no copy.

Sends the documents to sign now, the same as Send on the deal's signing package. Each document is filled in and checked, and each person gets one email with a link to the documents that are for them. The response has the documents that this call sent. A key with the no_sending limit cannot do this. Supports Idempotency-Key: a retry with the same key gets the first response and emails nobody again.

Emails the signer a new link to the documents they were sent, now, from the broker who sent them first. The response is the signing document. A key with the no_sending limit cannot do this. Supports Idempotency-Key: a retry with the same key gets the first response and emails nobody again.

Files that came in on email matched to the deal and that BrokerPlus holds for the broker. A held file is not on the deal file: the broker puts it there with accept, or dismisses it. Newest email first. By default only the files that wait for the broker.

One file that came in on email matched to the deal, and what the broker did with it.

Puts the file on the deal file as a new document, which BrokerPlus then classifies. document_id is the new document. If the file is already on the deal file, you get it as it is.

Keeps the file off the deal file. The email and its attachment stay in the inbox. If the file is already dismissed, you get it as it is.

The codes BrokerPlus uses for document_type, with a readable name and the folder each type goes in. Send one as document_type on an upload.

The PDFs on the Resources tab of a client's hub, oldest first, for example a guide for first-time buyers. Without deal_id, the brokerage PDFs that every client sees. With deal_id, the PDFs for that deal's client alone. A list never contains a download URL.

Adds a PDF to the Resources tab, as Client Requests > Resources in BrokerPlus does. Send deal_id to add it for that deal's client alone; without it, every client sees it. Send the file as multipart/form-data (fields file, name, deal_id), or as JSON with content_base64. Only a PDF of at most 20 MB is accepted, and each list holds at most 12. BrokerPlus does not tell the client, but the client sees the file at once, so a key with the no_sending limit cannot do this. Supports Idempotency-Key.

Removes the PDF from the Resources tab and from storage. You cannot undo this. A PDF for one deal's client needs write access to that deal.

The documents the broker's team asks for that are not in GET /v1/document-types, by label. The team adds them in its document library in BrokerPlus. Each has a custom: code that a document package can name.

Adds a document to the team's library, as Add Document in the BrokerPlus document library does. BrokerPlus makes its code from the label. Nothing reaches a client. Supports Idempotency-Key.

One document type of the broker's team. A type that was removed is not found.

Takes the type out of the team's library, so nobody can ask for it again. A request that a client already has keeps asking for it under its label.

The document packages of the broker's team, by name. A package is a named set of documents that the team asks for together, for example Self-Employed Ontario. In BrokerPlus, adding a package to a request ticks its documents. To ask a client for them through the API, send its document_types to POST /v1/deals/{id}/document-requests.

Adds a package to the broker's team, as Client Requests > Packages in BrokerPlus does. Nothing reaches a client. Supports Idempotency-Key.

The situations BrokerPlus can recognize on a submitted application, each as the package it starts out as. Add one to the team with POST /v1/doc-packages/samples/{key}.

Adds the sample for this situation to the team as an ordinary package. You can then change it like any other package. Nothing reaches a client.

One package of the broker's team, with its documents and the note under each.

Deletes the package. You cannot undo this. A request already sent to a client keeps the documents it asked for.

Changes only the fields you send. A request already sent to a client keeps the documents it asked for: a package is copied into a request, never linked.

The document's metadata plus a signed download URL valid for five minutes. Follow it, do not store it.

Deletes the file from the deal and from storage. You cannot undo this. When the client sent the file through the client hub, the client's copy goes too.

Rename the document, file it under another borrower on the deal, or keep it out of a new lender submission. Only the fields you send change.

The same move as a drag on the deal's document board. Send stage verified to mark the document checked and ready to go to a lender, with a folder to file it. Send the same stage with another folder to move a verified document between folders. Nothing goes to the client. To reject a document and ask the client for a new copy, use BrokerPlus: that request emails the client.

The notes brokers wrote on this document in its preview in BrokerPlus, newest first. Replies are in the list too, with parent_id set. Only the broker's team sees these notes. A client never does.

Adds a note to the document, as the notes panel of the document preview does. A teammate mentioned in the body is told, the same as in BrokerPlus. Nothing reaches a client. Supports Idempotency-Key.