# Onboarding Businesses Business onboarding requires making API calls for the primary **Business Application** object, as well as the secondary **Related Party Application** and **Document Request** objects. The primary **Business Application** object contains general information related to the business and the overall status of the application. Only one is needed per business. The secondary **Related Party Application** object contains personal information for authorized representatives, beneficial owners (if applicable), and a member of senior management. A Related Party Application is required for each of these individuals. The secondary **Document Request** object is a checklist of document requirements and is automatically generated based on information provided in the Business Application and Related Party Applications. When the Business Application, Related Party Application, and Document Request objects have been completed, the overall Business Application can be submitted for review. From there, the Business Application will either indicate additional document/information requirements or reach a terminal status. ## Business Application To begin, create the primary Business Application object using the **Create Application** and **Patch Application** endpoints: ```json { "name": string, "entity_type": "SOLE_PROPRIETOR" | "CORPORATE" | "LLC" | "PARTNERSHIP" | "NON_PROFIT" | "INCORPORATED_ASSOCIATION" | "UNINCORPORATED_ASSOCIATION", "doing_business_as": string, "identification_number": { "identification_number": string, "type": "TIN" | "EIN" | "NON_US_BUSINESS_ID" }, "address": { "street_address": string, "street_address2": string, "city": string, "postal_code": string, "state": string, // 2-character state code "country": string // ISO-3166 Alpha-2 country code }, "website": string, "contact": { "name": { "first_name": string, "middle_name": string, "last_name": string }, "phone_number": string, // e.164 format "email": string }, "formation_date": string, "risk_info": { // contains conditionally required fields, see below* "risk_categories": ["INTERNET_GAMBLING", "CANNABIS", "CRYPTOCURRENCY", "CROWDFUNDING", "FINANCIAL_OR_MONEY_MOVEMENT"], "company_mission": string, "has_current_enforcement_actions": boolean, "primary_regulator": string, "business_activity_location": "PRIMARILY_US" | "MIX_OF_US_AND_NON_US" | "PRIMARILY_NON_US", "source_of_funds": "INTERNAL_FUNDS" | "CLIENT_OR_EXTERNAL_FUNDS", "account_usage": "MONEY_STORAGE", "annual_revenue": "PRE_REVENUE" | "5M_OR_LESS" | "BETWEEN_5M_100M" | "100M_OR_MORE", "monthly_transactions": "5_OR_LESS" | "BETWEEN_5_AND_15" | "15_OR_MORE", "first_month_deposit": "1M_OR_LESS" | "BETWEEN_1M_AND_5M" | "BETWEEN 5M_AND_20M" | "BETWEEN_20M_AND_50M" | "50M_OR_MORE" }, "industry": { "industry": enum, // see below* "other_industry": string }, "agreement_consent": { "version": string, "timestamp": date } } ``` *Conditionally required fields for `risk_info`: | Diligence type | Trigger values | Conditionally required fields | | --- | --- | --- | | Standard | • `industry.industry` equals `"GAMBLING"`• `risk_info.risk_categories` contains `"INTERNET_GAMBLING"`, `"CANNABIS"`, or `"CROWDFUNDING"` | • `risk_info.company_mission`• `risk_info.source_funds` | | Crypto | `risk_info.categories` contains `"CRYPTOCURRENCY"` | Everything in "Standard" + `risk_info.has_current_enforcement_actions` | | Regulated | `risk_info.categories` contains `"FINANCIAL_OR_MONEY_MOVEMENT"` | Everything in "Crypto" + `risk_info.primary_regulator` | For the full list of possible enum values for `industry.industry`, see the [API Reference](/products/partner-api/reference/businesses/create-business-application), and expand the `IndustryInfo` object under the request schema. For `agreement_consent`, call **List Agreements** for the list of agreements to display to your customers: ```json { "version": string, "release_date": string, "documents": [ { "pdf_download_url": string, // PDF "title": string, "type": string, "category": string } ] } ``` After displaying the agreements to your customers, provide the appropriate `agreement_consent.version` in the Business Application. When the Business Application object has been completed, along with Related Party Applications and Document Requests (see below), call **Apply** with the `application_id` to submit the business application for review. After the application has been submitted, call **Get Application** to monitor the application `status`: | Application Status | Description | | --- | --- | | `CREATED` | The application has been created but not submitted for review. After the Business Application object, Related Party objects, and Document Requests have been completed, call **Apply** to update the overall application status to `SUBMITTED`Subsequent status: `SUBMITTED` | | `SUBMITTED` | The application has been submitted and is being reviewed.Subsequent statuses: `CLOSED`, `APPROVED`, `REJECTED`, `DOCUMENTS_NEEDED`, `MANUAL_REVIEW` | | `CLOSED` | The application has been closed due to inactivity. This is a terminal status. | | `APPROVED` | The application has been approved and a `customer_id` now exists for the business. This is a terminal status. | | `REJECTED` | The application has been rejected. This is a terminal status. | | `MANUAL_REVIEW` | The application is being manually reviewed based on provided documents.Subsequent statuses: `CLOSED`, `APPROVED`, `REJECTED`, `DOCUMENTS_NEEDED` | | `DOCUMENTS_NEEDED` | The application requires documentation. Call **List Document Requests** to view the outstanding list of documents, then call **Upload Documents** to submit each requested document. When all requested documents have been uploaded, the application status will automatically update to `PENDING`.Subsequent status: `PENDING` | | `PENDING` | If an application needed further action (for example `DOCUMENTS_NEEDED`), this status signifies the required actions are completed and the application is ready to be submitted again.Subsequent status: `SUBMITTED` | ## Controlling Application Status In the sandbox API, the first number of the Business ID (`identification_number`) allows you to control which status the application receives after applying: - ID starts with 2: `DOCUMENTS_NEEDED` - ID starts with 3: `MANUAL_REVIEW` - ID starts with 4: `APPROVED` - ID starts with 5. `REJECTED` - ID starts with anything else: Application ends in `MANUAL_REVIEW` ## Related Party Applications For each Related Party — defined as authorized representatives, beneficial owners (if applicable), and a member of senior management — create an application using the **Create Related Party Application** and **Update Related Party Application** endpoints: ```json { "name": { "first_name": string, "middle_name": string, "last_name": string }, "address": { "street_address": string, "street_address2": string, "city": string, "postal_code": string, "state": string, // 2-character state code "country": string // ISO-3166 Alpha-2 country code }, "date_of_birth": string, "identification_number": { "identification_number": string, "identification_type": "SSN" | "PASSPORT" | "NON_US_ID" }, "phone_number": string, // e.164 format "title": string, "roles": ["CONTROL_PERSON", "AUTHORIZED_REPRESENTATIVE"], "ownership_percentage": string, "citizenship": string, // ISO-3166 Alpha-2 country code "email": string } ``` You can also call **List Related Party Applications** and **Delete Related Party Application**. When each Related Party Application has been created, along with the Business Application and Document Requests, the overall application can be submitted using **Apply**. ## Document Requests Document Requests vary depending on the information provided in the Business Application and Related Party Application objects. Call the **List Document Requests** endpoint to retrieve the list of documents based on your application: ```json [ { "id": string, "type": enum, // see below* "status": "PENDING_UPLOAD" | "PENDING_REVIEW" | "APPROVED" | "INVALID", "name": string, "exception_reason": string } ] ``` For the full list of possible enum values for `type`, see the [API Reference](/products/partner-api/reference/businesses/list-document-requests-businesses), and expand the successful response schema. For each document request, call **Upload Document** to upload a `.png` file of the requested document. Uploading a document updates the Document Request status from `PENDING_UPLOAD` to `PENDING_REVIEW`. From there, the document will be reviewed and the status will move to either `APPROVED` or `INVALID`. If `APPROVED`, no further action is needed. If `INVALID`, an `exception_reason` will be provided as guidance on next steps. When all Document Requests have been provided (all requested documents have either `APPROVED` OR `PENDING_REVIEW` as the status), along with the Business Application and Related Party Applications, the overall application can be submitted using **Apply**.