Integration guide

Aggregator / Offtaker

Let suppliers and buyers apply for finance through your platform. Your business can also apply where the product allows it. Your customers continue using your platform; your server connects to eFaaS.

Who does what

Keep credentials on your server and call eFaaS from there. Customers use your platform and do not normally need a separate MightyFin login. MightyFin staff assess credit and approve funding. Your business’s approval does not replace theirs.

Keep your business registration documents separate from each customer’s identity and loan documents. Attach each document to the right person, business and application.

Application to servicing — authority and handoffs

Steps for your integration

  1. 1. Your administrator

    Set up API access

    Register your business and get credentials for the correct environment: sandbox or live. Ask for the permissions your application needs. Product access and live access need separate approval.

  2. 2. Your server

    Register the customer

    Create or find the customer in your business’s network. Keep the returned IDs for later API calls. Do not use a name or email in place of an ID. You cannot access another business’s customer records.

  3. 3. Your server

    Choose a product

    Read the available products and the selected product’s questions and document requirements. Build the form from those requirements; different products may need different information.

  4. 4. Customer on your platform

    Complete the application

    Record the customer’s permission. Create a draft and save the answers with the current revision number. Request an upload link, upload the files and check their status. Uploading a file does not mean it has passed the required checks.

  5. 5. Your authorised reviewer

    Review the business request, if required

    Some products require your business to approve the request before MightyFin reviews it. Use the current application version and documents. If these change, review again. Your approval does not approve the loan or release money.

  6. 6. Your server

    Send the application to MightyFin

    Attach the required documents and submit the completed application. Keep its ID and request key for safe retries. A request waiting for review is not an approved loan or spendable money.

  7. 7. MightyFin credit staff

    Review the application

    MightyFin may ask for more information. Show that request to the customer and send back the corrected information. Update the existing application; do not create another one to skip the review.

  8. 8. Customer on your platform

    Accept or decline the offer

    Show the actual offered amount and terms. They may differ from the request. To accept, send the quote ID and a reference to the customer’s agreement. Expired or replaced offers cannot be accepted.

  9. 9. MightyFin funding staff

    Approve payment

    Accepting an offer may create a loan account waiting for funds. It does not transfer money. MightyFin staff approve the funding source and destination. The loan becomes active only after payment is confirmed.

  10. 10. Your server and staff

    Track payments and amounts owed

    Read the loan account, payment schedule and balances. Show whether payments are pending, successful, failed or disputed. A timeout or a request being accepted does not prove payment completed.

Application API sequence

Use the API instructions for required fields, permissions and revision numbers. Check that draft and document APIs are available before depending on them.

GET  /v1/products
GET  /v1/products/{product_id}/application-requirements
POST /v1/credit/application-drafts
PUT  /v1/credit/applications/{application_id}/draft
POST /v1/credit/applications/{application_id}/documents/upload-sessions
PUT  /v1/credit/applications/{application_id}/documents/{document_id}/content
GET  /v1/credit/applications/{application_id}/documents/{document_id}
POST /v1/credit/applications/{application_id}/evidence
GET  /v1/credit/applications/{application_id}/commercial-review
POST /v1/credit/applications/{application_id}/commercial-review
POST /v1/credit/applications/{application_id}/submit
GET  /v1/credit/applications/{application_id}
GET  /v1/credit/applications/{application_id}/information-request
POST /v1/credit/applications/{application_id}/resubmit
GET  /v1/credit/applications/{application_id}/offer
POST /v1/credit/applications/{application_id}/accept

Only send corrections when they are requested. Cancellation is allowed at certain stages and cannot erase an accepted or funded loan. Retry the same action with the same key and body. Use GET to check the latest status.

Commercial review applies only when commercial_review_required is enabled for the selected product and applicant role. Writing that decision requires credit:commercial:write; ordinary application credentials do not receive it automatically. Send the current revision and snapshot hash, your review reference and a reason. This control must be deployed before enabling it on products.

Credit API reference

Payments to suppliers and from buyers

A supplier’s loan and the payment owed for their goods are separate amounts. Do not subtract one from the other unless the approved product and payment agreement allow it.

For buyer finance, an approved loan does not allow payment to any supplier. Follow the product’s rules for the supplier, order, delivery and payment. Check that the full process is available and tested before promising immediate payment.

Wallet money, approved credit, credit still available and the amount owed are different figures. Use the balances returned by the APIs. Adding money to a wallet does not increase a credit limit. You cannot see a customer’s activity with another business, and a shared limit must not be assumed.

Events, communication and recovery

MightyFin sends your business updates about its account. Your business sends messages to its customers. Subscribe to available webhook updates, verify their signatures and process each update ID once. Updates may arrive late or more than once. If unsure of a payment’s result, check its status instead of creating a new payment.

Your domain, branding and applicant experience are yours to build. Hosted screens or provider redirects apply only where the selected, approved verification flow requires them.

Acceptance checks before launch

  • Complete the journey with ordinary credentials and actual staff review, without database fixtures or bypassed approvals.
  • Exercise corrections, declined or reduced offers, expiry, stale revisions, cancellation and duplicate retries.
  • Demonstrate second-tenant isolation for applications, documents, facilities, reports and events.
  • Reconcile funding and repayments; test failures, timeouts, disputes and replay without duplicate postings.
  • Confirm product access, provider readiness, production activation, restore testing and agreed load thresholds separately from sandbox success.