Overview

The Mulligan Funding ISO API is a RESTful, HTTP-based API that enables Mulligan Funding's partners to build
custom client applications and automate their interaction with Mulligan Funding.

To begin your integration, you will need to operate within two distinct environments. All API requests must be directed to the appropriate base URL for your target environment:

• Sandbox (partner.sandbox.mulliganfunding.com): A testing environment to aid in implementing and validating your API submissions.
• Production (partner.mulliganfunding.com): The live production environment.

Structure

All API endpoints utilize standard HTTP verbs (GET, POST, PUT, and DELETE). Not all endpoints offer access to all HTTP verbs. Please refer to the specific endpoint documentation for more information.

Quickstart

To send an application to our API, first request an access-token using base64-encoded credentials (your client-id and client-secret):

export accessToken=$(curl --request POST \
     --url https://partner.mulliganfunding.com/iso/api/auth/oauth2/token \
     --header 'accept: application/json' \
     --header 'authorization: Basic MTIzNDpwYXNzd29yZA==' | jq .accessToken)

After that, you can send an application to the v1/application endpoint:

curl --request POST \
     --url https://partner.mulliganfunding.com/iso/api/v1/application \
     --header 'accept: application/json' \
     --header "authorization: Bearer ${accessToken}" \
     --header 'content-type: application/json'
     -d @application.json

Note: see the Submitting Applications documentation for the structure of this document.

The above POST will return a JSON payload like this:

{"application_id": "123456789"}

Finally, you can add files to this submission by sending them to the document endpoint:

curl --request POST \
     --url https://partner.mulliganfunding.com/iso/api/v1/document \
     --header 'accept: application/json' \
     --header "authorization: Bearer ${accessToken}" \
     --header 'content-type: multipart/form-data' \
     --form application_id=123456789 \
     --form type=bank_statement \
     --form doc='@bank%20statement-generic.pdf'

See Create Document for more information

Versioning

All routes (except authentication, oauth, and token routes) should include the version number in the path prefix.

Note: previous API-integrations may use paths such as: /iso/api/application and /iso/api/document. These paths are now deprecated in favor of the versioned-endpoints, all prefixed with v1.

Following are the updated endpoints you should use:

• /iso/api/application -> /iso/api/v1/application
• /iso/api/document -> /iso/api/v1/document
• /iso/api/documents->/iso/api/v1/documents
• /iso/api/offers -> /iso/api/v1/offers
• /iso/api/offer->/iso/api/v1/offer
• /iso/api/webhooks -> /iso/api/v1/webhooks

The /auth endpoints are unchanged.

Eventually, the deprecated paths will be removed: please update your integrations if you are still relying on the old paths.

Error Handling

The API uses standard HTTP response codes. If a request fails, the API returns a JSON error object shaped like this:

{
  "error": "Validation failed for POST /v1/application",
  "path": "/v1/application",
  "detail": "Validation failed for POST /v1/application",
  "extra": [
    {
        "message": "Field required",
        "key": "application"
    },
    {
        "message": "Field required",
        "key": "company"
    }
  ]
}

Note: If an error occurs during application or document submission, the data was not received and must be corrected before resubmitting.

For more error examples, see Errors.

We're here to help!

If you get stuck, shoot us an email and we'd be happy to assist you in your implementation.