Webhooks and emails

Email notifications

Besides webhooks, Multigate sends some emails to people in your business when things happen on your account. This page lists every email a partner can receive, who receives it, and which API calls or events cause it.

Build on webhooks, not emails

Emails are for people. They have no signature, no delivery guarantee and no fixed format, and the same email can occasionally arrive twice. Your systems should react to webhooks; treat emails as a courtesy copy for your operations team.

Who receives emails

Recipient	Who that is	How to change who receives it
The initiating user	The user who created the transfer or customer. For API calls, that is your API user's email address.	Make sure your API user's email is a mailbox someone reads (for example a shared operations inbox), or forward its emails with a mail rule.
Your business contact	The business contact email on your client profile, set when your business was onboarded.	You can't change it yourself, through the API or your profile. Ask Multigate support.
Your approvers	Users in your business with the matching permission: approve customers, approve account linking, or manage account credentials.	Your admin gives or removes the permission in the dashboard.
The account officer	The account officer email you put on a bank account linking request.	Use the right address when you submit the request.
Your trade finance users	Every user in your business who holds the trade finance permission the step needs: approve for approval requests, manage (and sometimes view) for outcomes, all three for newly received instruments.	Your admin gives or removes the permission in the dashboard.
Alert and report recipients	The addresses you list on a lifecycle alert or scheduled report.	Set them when you create the alert or report.

Emails come from app@multigate.app, in the sandbox and in production. Add it to your allow-list so they don't land in spam. If an address should stop receiving a type of email, ask Multigate support: delivery can be switched off per address or domain.

Sandbox emails are real emails

The sandbox sends real emails, with links to the sandbox web app: to your users, your business contact, and the account officer email you put on a linking request. Use addresses you control in test data, on real domains: production refuses disposable domains such as yopmail.com. See Sandbox vs production.

Emails by trigger

Payouts

Email (subject)	Recipient	Sent when	Caused by
Transfer Notification	The initiating user	A transfer starts processing, and again when it completes or fails. Each part of a split NGN transfer sends its own.	Create a transfer, each item of a bulk transfer, and approval of a transfer in the dashboard
Transaction Declined	The initiating user	An approver in your business declines a transfer that was waiting for approval. Also sent for remittances.	A decline in the dashboard

No email is sent for: a transfer waiting for approval (approvers aren't emailed; they see it in the dashboard), remittances that complete or fail, refunds, fee look-ups, validation and name enquiry.

Collections

Email (subject)	Recipient	Sent when	Caused by
Payment Received	Your business contact	Money is credited to one of your virtual accounts, a customer's, or a receivable's account.	A payer's transfer (or the sandbox inflow simulator)
Rejected Inflow Transaction	Your business contact	An incoming payment is rejected, for example because the account or its owner is disabled, or a dynamic account received the wrong amount. The email text always says the account is disabled.	A payer's transfer

Inflows into your customers' accounts are emailed to your business contact, not to the customer. When auto-sweep to a pool account applies, the email goes to the pool account's business. "Payment Received" is sent even when your business has agreed to skip inflow webhooks for a currency. No email is sent when a dynamic account receives its payment and closes.

Customers

Email (subject)	Recipient	Sent when	Caused by
Sub-client Creation Request for Approval	Your approvers	A customer is submitted by a user who can't approve customers, so a second person must approve.	Submit a customer for review
Subclient Creation Request Approved - {customer}	The user who created the customer (for API calls, your API user)	An approver in your business approves the request. The customer then goes to Multigate's review.	An approval in the dashboard
Sub-client Creation Request Declined	The user who created the customer	An approver in your business declines the request.	A decline in the dashboard

Creating, updating and uploading documents for a customer send no email. Multigate's own review result arrives as the subclient_approved webhook, not by email.

Linked accounts

Email (subject)	Recipient	Sent when	Caused by
Bank Account Linking Request	Users in your business who can approve account linking	A request to link a bank account is submitted (one email per account). The signed documents are attached.	Submit a linking request
Bank Account Linking Request (same subject; the body says the request was approved)	The account officer email on the request, and the bank's linking contacts	An approver in your business approves the request. The signed documents are attached.	Approve or decline a linking request
Account Activation Confirmation - {bank}	Users in your business who manage account credentials	At least one row of your bank API credentials upload succeeds. Lists the activated account numbers.	Upload bank credentials

Declining a linking request sends no email.

Receivables and compliance

Email (subject)	Recipient	Sent when
Receivables Settlement Initiated	Your business contact	A scheduled settlement of collected receivables starts.
Action Required: Update Document for Your Account	Your business contact	A daily check (weekly in the sandbox) finds a KYC document on your profile that is about to expire.

Trade finance

Trade finance has no webhooks: these emails, and polling the lists, are how you learn about changes. Links in them open the dashboard. {reference} is the LC number or the guarantee's undertaking number.

Email (subject)	Recipient	Sent when
Export LC Created	Your trade finance users	A bank's export LC arrives.
Export LC Advice Request, Guarantee Advice Request	Approvers	A maker completes or updates an export LC or inward guarantee.
Export LC Approved, Export LC Declined, Guarantee Approved, Guarantee Declined	Makers (and viewers)	An approver advises or declines it.
Export LC Update Request, Guarantee Update Request	Approvers	A maker requests a change to an advised export LC or inward guarantee.
Export LC Update Approved / Declined, Guarantee Update Approved / Declined	Makers	The approver decides.
Inward Guarantee Received	Your trade finance users	A bank's inward guarantee arrives.
Amendment Requested by Issuing Bank for Export Letter of Credit {reference} (or … for Inward Guarantee {reference})	Your trade finance users	The bank amends an export LC or inward guarantee.
Request to Respond to Amendment for Export Letter of Credit {reference} (or … for Inward Guarantee {reference})	Approvers	A maker accepts or refuses the amendment.
Amendment Accepted / Refused for Export Letter of Credit {reference} (or … for Inward Guarantee {reference}), Request to Respond to Amendment Declined	Makers	The approver approves or rejects the response.
Import LC Approval Request, Outward Guarantee Approval Request	Approvers	A maker submits an application.
Import LC Approved / Declined, Outward Guarantee Approved / Declined	Makers	The approver decides.
Import LC Issued, Outward Guarantee Issued	Makers	The bank issues it.
Amendment of Import LC Application Approval Request, Amendment of Guarantee Application Approval Request	Approvers	A maker submits an amendment.
Amendment of Import LC Application Approved / Declined, Amendment of Guarantee Application Approved / Declined	Makers	The approver reviews it.
Instrument Amended, Amendment Accepted, Amendment Refused	Makers	The bank accepts the amendment, then the beneficiary accepts or refuses it.
Outward Instrument Update - Approval Required	Approvers	A maker submits an instrument update (import LC or outward guarantee).
Outward Instrument Update - Approved / Declined	The maker who submitted it	The approver decides.
Trade Finance Record Upload - Approval Required	Approvers	A maker submits a manual record.
Trade Finance Record Upload Approved / Declined	Makers	The approver decides.
Payment Due in {n} Day(s) - {reference}, Instrument Expiry Reminder - {n} Days Remaining - {reference}	The alert's recipients	A lifecycle alert fires. Sent once per recipient.
Trade Finance Report - {report name}	The report's recipients	A scheduled report has data for the period. One CSV file attached, with every instrument type combined.

Saving drafts, uploading documents, and the dashboard send no email.

API calls that never send email

Generating or revoking API keys, opening wallets and virtual accounts, creating receivables, saving beneficiaries, conversions (quote and lock), refunds, webhook configuration and statement downloads send no email.

Some emails are about what people do in the dashboard and are not listed on this page: passkey changes, changes to your organisation's security policy, and a transfer sent or approved in the dashboard that is held for a security review. API calls never cause them, because those checks don't apply to API keys or API users (see Authentication).

Emails contain account details

Transfer, inflow, linking and credential emails include full account numbers and amounts. Restrict access to the mailboxes that receive them.