> This page is for NT Connect. > For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://partner.ninjatrader.com/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://partner.ninjatrader.com/_mcp/server. # Funding disclosures Before a user can fund with a debit card, a digital wallet, or ACH, they must have signed the funding disclosures that apply to that flow. Your integration resolves the right documents, shows each one, collects the signature, and confirms it was stored. > **Warning** > > These endpoints are Live-only. Do not send them to the Demo base URL. ## Prerequisites Your integration needs: * a bearer access token for the user; * the user's numeric user ID; * the `clearingHouseId` of the account being funded, from the account record; * a PDF viewer in your client. The preview is returned as base64, not as a URL. ## Decide which documents the flow needs Two documents exist. Which ones apply depends on the funding flow and on whether the user is **adding a payment method** or **funding with one already saved**. | Flow | Documents, in signing order | | ---------------------------- | ------------------------------------------------------------------------------------------------------- | | ACH | Payment Processor Disclosure and Authorization | | Add a debit card | Payment Processor Disclosure and Authorization, then Form of Risk Disclosure and Customer Authorization | | Fund with a saved debit card | Only those not already signed | | Apple Pay or Google Pay | Payment Processor Disclosure and Authorization, then Form of Risk Disclosure and Customer Authorization | A previously signed document satisfies the requirement, with one exception: **adding a payment method re-collects the payment processor authorization every time**, even when the user signed it for an earlier method. The form of risk disclosure is collected once. ## Resolve the template ID by name Document names are the stable identifier. The numeric `agreementDocumentTemplateId` differs between environments and between clearing houses, so resolve it at runtime and never hard-code it. Call [`agreementDocumentTemplateList`](/connect/api/rest-api-endpoints/users/agreement-document-template-list) and match on the exact name: ```http GET /v1/agreementDocumentTemplate/list ``` A name can appear several times, once per clearing house. Select in this order: 1. the row whose `clearingHouseId` matches the account's; 2. otherwise the row with no `clearingHouseId`. Never take the first match, and never use a row belonging to a different clearing house. ## Check what the user has already signed Read the user's signed records with `userSignedDocumentLDependents`: ```http GET /v1/userSignedDocument/ldeps?masterids=654321 ``` A document counts as signed when a record carries its `documentName`. Compare against the list from the previous step and drop the documents the flow does not still need. > **Note** > > A signed record is not scoped to a clearing house. If the same document name exists for more than one clearing house, a record from either satisfies the check. ## Preview the document Retrieve the PDF with `downloadUserDocumentPreview`, using the resolved template ID: ```json { "agreementDocumentTemplateId": 186, "pdfFields": {} } ``` The response returns the document in `content` as base64. Decode it and display it to the user. > **Warning** > > Do not enable your sign control until the document has actually rendered. Treating a successful response as proof the user saw the document means collecting a signature on an unread disclosure. ## Collect the signature Call `signUserDocument` once per document: ```json { "agreementDocumentTemplateId": 186, "signature": "Jane Doe", "date": "10/12/2026", "pdfFields": {}, "allowMultiple": true } ``` | Field | Requirement | | --------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `signature` | Must match the full name on the applicant's contact record. A mismatch is rejected with `Signature should be the same as full name of the applicant`. | | `date` | `MM/DD/YYYY`. | | `pdfFields` | Send `{}` for both funding disclosures. | | `allowMultiple` | `true` permits a further signature for a template the user has already signed. Set it when you are adding a payment method and re-collecting the payment processor authorization. Omitted or `false`, a second attempt is refused with `User already has a signed