> ## Documentation Index
> Fetch the complete documentation index at: https://docs.business.blaaiz.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Updates & improvements

> Release notes for Blaaiz docs and API. Follow along for new endpoints, UI polish, and integration guides.

<div className="changelog-page">
  <div className="changelog-list">
    <div className="changelog-item">
      <div className="changelog-date">21/05/2026</div>

      <div className="changelog-card">
        <h3>List customers: filters and opt-in pagination</h3>

        <p>
          <a href="/api-reference/customer/list">GET /customer</a> now accepts
          optional exact-match filters and opt-in pagination so you can recover
          a single customer by identifier or page through large result sets.
        </p>

        <ul>
          <li>
            New filters: <code>email</code>, <code>id\_number</code>,{" "}
            <code>registration\_number</code>, <code>verification\_status</code>{" "}
            (<code>PENDING</code> / <code>PROCESSING</code> /{" "}
            <code>VERIFIED</code> / <code>REJECTED</code>), and{" "}
            <code>type</code> (<code>individual</code> / <code>business</code>).
            All are scoped to your business and combine with each other.
          </li>

          <li>
            Pass <code>?paginate=true</code> to receive a paginated envelope
            (<code>data</code>, <code>links</code>, <code>meta</code>) with 15
            items per page. The paginated path returns results newest-first.
          </li>

          <li>
            <strong>Backwards compatible.</strong> Omitting{" "}
            <code>paginate</code> returns the existing{" "}
            <code>{"{message, data: [...]}"}</code> shape unchanged.
          </li>
        </ul>
      </div>
    </div>

    <div className="changelog-item">
      <div className="changelog-date">06/05/2026</div>

      <div className="changelog-card">
        <h3>New: <code>kyb\_scope</code> on business customers — Standard and Minimal KYB</h3>

        <p>
          Business customers now carry a <code>kyb\_scope</code> field that picks
          one of two onboarding paths:
        </p>

        <ul>
          <li>
            <strong><code>FULL</code></strong> (Standard KYB) — business identity
            (name, registration number, country of incorporation), beneficial
            owners summing to 100% ownership, an ID file for each owner, plus a
            formation document. Eligible for NGN, USD, GBP, and EUR Virtual Bank
            Accounts.
          </li>

          <li>
            <strong><code>MINIMAL</code></strong> — same business identity as
            Full, <strong>without owners or per-owner ID files</strong>, plus a
            formation document. Eligible for NGN VBAs only.
          </li>
        </ul>

        <p>
          <strong>Who can use Minimal:</strong> Minimal is gated by an admin-controlled
          allow list — typically Nigerian platforms collecting payments in naira
          for their own customers. Allow-listed platforms default to{" "}
          <code>MINIMAL</code> when they don't send <code>kyb\_scope</code>, and
          can pass <code>FULL</code> explicitly when they need non-NGN currencies.
          Platforms not on the list default to <code>FULL</code>; sending{" "}
          <code>MINIMAL</code> returns <code>422</code>. Contact{" "}
          <a href="mailto:support@blaaiz.com">[support@blaaiz.com](mailto:support@blaaiz.com)</a> if your use
          case is genuinely NGN-only.
        </p>

        <p>
          <strong>Upgrading is one-way.</strong> Use{" "}

          <a href="/api-reference/customer/upgrade-kyb-scope">
            POST /customer/{"{id}"}/upgrade-kyb-scope
          </a>

          {" "}

          to promote a <code>MINIMAL</code> customer to <code>FULL</code> by
          adding beneficial owners. There is no downgrade. After the upgrade,
          upload owner ID files and call <code>/submit</code> to re-verify under
          the Standard checks.
        </p>

        <p>
          <strong>How businesses identify themselves.</strong> Every business
          customer (Minimal or Full) identifies via{" "}
          <code>registration\_number</code> + <code>incorporation\_country</code>.
          The <code>id\_type</code> and <code>id\_number</code> fields are
          individual-only — sending them on a business create or update returns
          422\.
        </p>

        <p>
          <strong>Backwards compatibility.</strong> Existing business customers
          (created before this release) are tagged <code>kyb\_scope=MINIMAL</code>{" "}
          and have their canonical identity columns backfilled from the legacy
          ones. Their NGN VBAs continue to work; the legacy columns stay
          populated for read-side compatibility. To enable non-NGN currencies
          for an existing business customer, call the upgrade endpoint.
        </p>

        <p>
          <strong>Read these:</strong>
        </p>

        <ul>
          <li><a href="/guides/kyb/overview">Business customer KYB — Overview</a> (Two paths section, what we check before /submit, upgrade flow).</li>
          <li><a href="/guides/kyb/onboarding">Onboarding a business customer</a> (Minimal KYB onboarding section + Upgrading section).</li>
          <li><a href="/api-reference/customer/upgrade-kyb-scope">POST /customer/{"{id}"}/upgrade-kyb-scope</a> — new endpoint reference.</li>
        </ul>
      </div>
    </div>

    <div className="changelog-item">
      <div className="changelog-date">26/04/2026</div>

      <div className="changelog-card">
        <h3>Breaking: business-type customers now use a dedicated KYB flow</h3>

        <p>
          <strong>Does this affect you?</strong>
        </p>

        <ul>
          <li>
            <strong>You only create <code>type=individual</code> customers</strong> —
            nothing changes. Continue using{" "}
            <a href="/api-reference/file/create">POST /file/get-presigned-url</a> +{" "}
            <a href="/api-reference/customer/upload-files">POST /customer/{"{id}"}/files</a>.
            That flow is unchanged.
          </li>

          <li>
            <strong>You create <code>type=business</code> customers</strong> — yes,
            you must migrate. The legacy{" "}
            <code>POST /customer/{"{id}"}/files</code> with <code>id\_file=\<cert\_of\_inc></code>{" "}
            no longer triggers verification for business customers. The file is still
            stored, but our verification pipeline does not look at it for businesses,
            and <code>/submit</code> will return <code>422</code> with a readiness error.
          </li>

          <li>
            <strong>Your existing <code>VERIFIED</code> business customers</strong> are
            untouched. They remain <code>VERIFIED</code> and valid for every operation
            they were valid for before. You only need to migrate the flow you use to
            verify <strong>new</strong> business customers.
          </li>
        </ul>

        <p>
          <strong>Migration at a glance.</strong>
        </p>

        <ul>
          <li>
            <strong>Before</strong> (no longer works for business):{" "}
            <code>POST /customer</code> with{" "}
            <code>type=business</code>, <code>id\_type=certificate\_of\_incorporation</code>{" "}
            → upload via <code>/file/get-presigned-url</code> →{" "}
            <code>POST /customer/{"{id}"}/files</code> with <code>id\_file</code>.
          </li>

          <li>
            <strong>Now</strong>:{" "}
            <code>POST /customer</code> with <code>type=business</code> +{" "}
            <code>business\_name</code> + <code>registration\_number</code> +{" "}
            <code>incorporation\_country</code> + (optional)<code>owners</code> array
            (or add owners later via <code>PUT /customer/{"{id}"}</code>) → upload
            owner ID files via{" "}
            <code>POST /customer/{"{customer}"}/owner/{"{owner}"}/file/presigned-url</code>{" "}
            and{" "}
            <code>POST /customer/{"{customer}"}/owner/{"{owner}"}/files</code> →
            register KYB documents via{" "}
            <code>POST /customer/{"{customer}"}/document/presigned-url</code> and{" "}
            <code>POST /customer/{"{customer}"}/document</code> → finalize with{" "}
            <a href="/api-reference/customer/submit"><code>POST /customer/{"{customer}"}/submit</code></a>.
          </li>

          <li>
            <strong>
              Customer-level <code>id\_type</code> and <code>id\_number</code> are
              prohibited on business customers
            </strong>

            . Use <code>registration\_number</code> +{" "}
            <code>incorporation\_country</code> as the canonical identifier. Sending{" "}
            <code>id\_type</code> or <code>id\_number</code> on a{" "}
            <code>type=business</code> create or update returns <code>422</code>.
            Individuals continue to require <code>id\_type</code> +{" "}
            <code>id\_number</code> as before.
          </li>

          <li>
            <strong>Uniqueness:</strong>{" "}
            <code>registration\_number</code> is now unique within your business per{" "}
            <code>incorporation\_country</code> — two of your business customers cannot
            share the same <code>(registration\_number, incorporation\_country)</code>{" "}
            pair. The same number across different incorporation countries is fine.
          </li>

          <li>
            <strong>Country fields are explicit and split.</strong> A business
            customer now carries three ISO alpha-2 country codes, each with a
            distinct meaning:

            <ul>
              <li>
                <code>incorporation\_country</code> — the legal jurisdiction
                the company is registered in. Top-level, business-only,
                required.
              </li>

              <li>
                <code>country</code> — the registered-address country.
                Top-level, required for both individuals and businesses.
                For businesses, must equal <code>incorporation\_country</code>{" "}
                (a company's registered office sits in its country of
                incorporation by company law). The cross-field check is
                enforced at validation time, including on update — when
                changing the jurisdiction, send both fields together.
              </li>

              <li>
                <code>operating\_country</code> — the operating-address
                country, on KYC data. Business-only. Required whenever any
                other <code>operating\_\*</code> field is supplied. Can
                differ from the other two when the business operates from
                a different jurisdiction.
              </li>
            </ul>

            Postal-code validation is anchored per address:{" "}
            <code>zip\_code</code> against <code>country</code>,{" "}
            <code>operating\_zip\_code</code> against{" "}
            <code>operating\_country</code>. Same rules across{" "}
            <code>POST /customer</code>, <code>PUT /customer/{"{id}"}</code>,
            and <code>POST /customer/{"{id}"}/kyc-data</code>.
          </li>

          <li>
            <strong>Type-specific fields are strictly scoped.</strong>{" "}
            Sending fields that don't apply to the customer's{" "}
            <code>type</code> (for example, <code>operating\_\*</code> on{" "}
            <code>type=individual</code>, or business KYB fields on an
            individual) fails the entire request with <code>422</code>.
            Send only what applies.
          </li>

          <li>
            <strong>
              Explicit <code>null</code> on update clears nullable fields
            </strong>

            . On <code>PUT /customer/{"{id}"}</code>, sending a property as{" "}
            <code>null</code> writes <code>null</code> to the column. Omit
            the property to leave it unchanged. Applies to the customer
            object and to entries inside the <code>owners</code> array.
          </li>

          <li>
            The certificate-of-incorporation <strong>file</strong> goes into the new
            KYB document collection (<code>type=CERTIFICATE\_OF\_INCORPORATION</code>)
            instead of through <code>/files</code>.
          </li>
        </ul>

        <p>
          <strong>Readiness floor that <code>/submit</code> enforces for business customers</strong>{" "}
          (each returns <code>422</code> with a specific message; same checks
          run on initial submit and on re-submit after a <code>REJECTED</code>{" "}
          verdict):
        </p>

        <ul>
          <li>
            <strong>Customer-level identity</strong> —{" "}
            <code>business\_name</code>, <code>registration\_number</code>, and a
            valid ISO <code>incorporation\_country</code> are all set;{" "}
            <code>country</code> equals <code>incorporation\_country</code>.
          </li>

          <li>At least one beneficial owner.</li>

          <li>
            <strong>
              Owner <code>ownership\_percentage</code> values sum to exactly 100
            </strong>

            . 99.99% won't pass.
          </li>

          <li>
            <strong>Owner emails are unique within the customer</strong>{" "}
            (case-insensitive).
          </li>

          <li>
            <strong>Per-owner ID slot consistency</strong> — every owner has{" "}
            <code>id\_document\_front</code>;{" "}
            <code>drivers\_license</code> / <code>id\_card</code> /{" "}
            <code>resident\_permit</code> require <code>id\_document\_back</code>;{" "}
            <code>passport</code> must not have a back image.
          </li>

          <li>
            <strong>Per-owner identity invariants</strong> —{" "}
            <code>date\_of\_birth</code> is at least 18 years ago,{" "}
            <code>id\_expiry\_date</code> is strictly after today, and ISO codes
            (<code>nationality</code>, <code>country</code>,{" "}
            <code>id\_document\_country</code>) are valid alpha-2 where set.
          </li>

          <li>
            At least one KYB document of a formation type:{" "}
            <code>CERTIFICATE\_OF\_INCORPORATION</code>,{" "}
            <code>ARTICLES\_OF\_INCORPORATION</code>,{" "}
            <code>BENEFICIAL\_OWNERSHIP\_CERTIFICATE</code>,{" "}
            <code>INCORPORATION\_DOCUMENTS</code>, or <code>CAC\_STATUS\_REPORT</code>.
          </li>
        </ul>

        <p>
          <strong>Lock matrix.</strong> A child record (owner or document) is
          locked if its own <code>status</code> is <code>APPROVED</code> or{" "}
          <code>PROCESSING</code>, OR the parent customer is in{" "}
          <code>PROCESSING</code> or <code>VERIFIED</code>. Edits to locked
          records return <code>400</code>. Wait for{" "}
          <code>customer.status\_changed</code> before attempting edits.
        </p>

        <p>
          <strong>Editing a <code>REJECTED</code> owner or document
          auto-resets it.</strong> Any field change or file replacement on a
          previously-rejected owner or document flips its <code>status</code>{" "}
          back to <code>PENDING</code> and clears its{" "}
          <code>admin\_comments</code>. The corrected record is re-routed
          through review on the next <code>/submit</code>. Records that are{" "}
          <code>APPROVED</code> stay locked and aren't re-reviewed.
        </p>

        <p>
          <strong>What's new in the response shape.</strong>{" "}
          <a href="/api-reference/customer/get">GET /customer/{"{id}"}</a> now returns:
        </p>

        <ul>
          <li>
            <code>owners\[]</code> — beneficial owners with per-record{" "}
            <code>status</code> (<code>PENDING</code> / <code>PROCESSING</code> /{" "}
            <code>APPROVED</code> / <code>REJECTED</code>) and{" "}
            <code>admin\_comments</code> (array of strings).{" "}
            <code>APPROVED</code> and <code>PROCESSING</code> owners are locked from
            edits.
          </li>

          <li>
            <code>documents\[]</code> — KYB document collection with the same{" "}
            <code>status</code> + <code>admin\_comments</code> shape and the same lock
            semantics. Note: this replaces nothing — it is a new field on the customer.
          </li>

          <li>
            On <code>customer.status\_changed</code> with{" "}
            <code>new\_status=REJECTED</code> for a business customer, render each
            owner's and each KYB document's <code>admin\_comments</code> entries to your
            end customer as separate bullets. Rejected items are editable;{" "}
            <code>APPROVED</code> items stay locked. Fix and call <code>/submit</code>{" "}
            again to re-review only the items you changed.
          </li>
        </ul>

        <p>
          <strong>Webhook contract.</strong>{" "}
          <code>customer.status\_changed</code> remains the single customer-level event;
          you do not need to update your webhook handler. Inspect{" "}
          <code>old\_status</code> and <code>new\_status</code> as before. Business
          customers introduce one new <code>new\_status</code> value:{" "}
          <code>PROCESSING</code>, fired right after <code>/submit</code>. There are{" "}
          <strong>no</strong> per-owner or per-document webhooks — the customer-level
          event is the only signal.
        </p>

        <p>
          <strong>Timeline expectations.</strong> Individual KYC remains a
          minutes-to-2-hours process. Business KYB review typically takes{" "}
          <strong>1–5 business days</strong>. Wait for{" "}
          <code>customer.status\_changed</code>; do not raise support tickets within
          the standard window.
        </p>

        <p>
          <strong>Currency eligibility.</strong> Verified business customers on{" "}
          <code>kyb\_scope=FULL</code> can hold NGN, USD, GBP, and EUR Virtual Bank
          Accounts. <code>kyb\_scope=MINIMAL</code> customers are NGN-only. For
          payout-currency coverage on business recipients, contact support.
        </p>

        <p>
          Read these before migrating:{" "}
          <a href="/guides/kyb/overview">Business customer KYB overview</a>,{" "}
          <a href="/guides/kyb/onboarding">Onboarding a business customer</a>{" "}
          (full curl walkthrough + a "Common mistakes" section that calls out the
          /files trap),{" "}
          <a href="/guides/kyb/handling-rejections">Handling KYB rejections</a>, and{" "}
          <a href="/faq/kyb">KYB FAQ</a>.
        </p>
      </div>
    </div>

    <div className="changelog-item">
      <div className="changelog-date">06/04/2026</div>

      <div className="changelog-card">
        <h3>PHP SDK Now Available</h3>

        <p>
          The official framework-agnostic PHP SDK for the Blaaiz Platform API is
          now available on Packagist. It handles authentication, request signing,
          and error handling out of the box.
        </p>

        <ul>
          <li>
            Install via Composer: <code>composer require blaaiz/blaaiz-php-sdk</code>
          </li>

          <li>
            Works with any PHP 8.1+ project — no framework dependency required.
          </li>

          <li>
            For Laravel-specific features, the{" "}
            <a href="/guides/sdks">Laravel SDK</a> is also available.
          </li>
        </ul>

        <p>
          See the <a href="/guides/sdks">SDKs page</a> for all available SDKs.
        </p>
      </div>
    </div>

    <div className="changelog-item">
      <div className="changelog-date">05/04/2026</div>

      <div className="changelog-card">
        <h3>Customer ID Now Required for All Virtual Bank Accounts</h3>

        <p>
          The <code>customer\_id</code> field is now <strong>required</strong> when
          creating a Virtual Bank Account for all currencies, including NGN. Previously,
          NGN allowed creating accounts without a customer by passing an{" "}
          <code>account\_name</code> instead — this is no longer supported.
        </p>

        <ul>
          <li>
            <code>customer\_id</code> is now a required field in the{" "}
            <a href="/api-reference/virtual-bank-account/create">Create Virtual Bank Account</a>{" "}
            request for all currencies (NGN, GBP, EUR, USD).
          </li>

          <li>
            The <code>account\_name</code> request parameter has been removed.
          </li>

          <li>
            The customer must have <code>verification\_status</code> of{" "}
            <code>VERIFIED</code> before a Virtual Bank Account can be created.
          </li>
        </ul>

        <p>
          <strong>Action required:</strong> If your integration creates NGN Virtual
          Bank Accounts without a <code>customer\_id</code>, you must update your
          integration to create and verify a customer first.
        </p>
      </div>
    </div>

    <div className="changelog-item">
      <div className="changelog-date">04/04/2026</div>

      <div className="changelog-card">
        <h3>Back ID Document Support for Customer Verification</h3>

        <p>
          The File API and Upload Files endpoint now support back-side identity
          document uploads for two-sided documents (e.g. driver's license).
        </p>

        <ul>
          <li>
            Added <code>identity\_back</code> as a new{" "}
            <code>file\_category</code> option in the File API presigned upload
            endpoint.
          </li>

          <li>
            Added <code>id\_file\_back</code> as a new optional parameter in the
            Upload Files for a Customer endpoint.
          </li>

          <li>
            Back ID uploads are optional — only needed when the identity
            document has two sides. Single-sided documents (passport,
            certificate of incorporation) do not require a back upload.
          </li>

          <li>
            The <code>id\_file</code> (front ID) remains the verification
            trigger. Other files (back ID, liveness check, proof of address)
            can be uploaded before or alongside <code>id\_file</code> without
            triggering verification.
          </li>

          <li>
            Rejected customers can now re-upload documents and resubmit for
            verification without requiring a manual reset.
          </li>

          <li>
            Uploads are now blocked while verification is actively in progress
            to prevent document mutation during review.
          </li>
        </ul>
      </div>
    </div>

    <div className="changelog-item">
      <div className="changelog-date">16/03/2026</div>

      <div className="changelog-card">
        <h3>Granular OAuth Scopes and Credential Rotation</h3>

        <p>
          OAuth credentials now support granular scopes and scope bundles,
          giving integrators fine-grained control over API access.
        </p>

        <ul>
          <li>
            Added documentation for 21 individual OAuth scopes (e.g.{" "}
            <code>wallet:read</code>, <code>payout:create</code>,{" "}
            <code>webhook:write</code>) and 6 scope bundles (e.g.{" "}
            <code>full-access</code>, <code>read-only</code>,{" "}
            <code>payouts</code>).
          </li>

          <li>
            Added credential rotation guide — rotate credentials from the
            dashboard to change scopes or recover from a compromised secret.
          </li>

          <li>
            Webhook registration endpoint now returns a{" "}
            <code>signing\_secret</code> in the response. Store this securely
            to verify <code>x-blaaiz-signature</code> headers.
          </li>

          <li>
            Legacy API key creation is now disabled. Legacy API key
            authentication will be removed soon.
          </li>
        </ul>
      </div>
    </div>

    <div className="changelog-item">
      <div className="changelog-date">15/03/2026</div>

      <div className="changelog-card">
        <h3>OAuth Authentication and Webhook Signing Secret</h3>

        <p>
          Blaaiz Platform API authentication is now documented around OAuth
          client credentials for integrations.
        </p>

        <ul>
          <li>
            Added OAuth token acquisition guidance for API access.
          </li>

          <li>
            Updated guides and API reference examples to use Bearer tokens
            instead of legacy API key headers.
          </li>

          <li>
            Clarified that webhook signature verification uses a dedicated
            webhook <code>signing\_secret</code>, not an API credential secret.
          </li>

          <li>
            Marked legacy API key usage as temporary and advised all integrators
            to switch fully to OAuth immediately.
          </li>
        </ul>
      </div>
    </div>

    <div className="changelog-item">
      <div className="changelog-date">15/03/2026</div>

      <div className="changelog-card">
        <h3>Common Use Cases Guide</h3>

        <p>
          We added a new{" "}
          <a href="/guides/common-use-cases">Common use cases</a>{" "}
          guide that walks through the most popular patterns businesses build with the Blaaiz Platform API.
        </p>

        <ul>
          <li>Cross-border remittances — collect in one currency, pay out in another.</li>
          <li>Marketplace and platform payouts — disburse to sellers across countries.</li>
          <li>Payroll for distributed teams — pay employees in their local currency.</li>
          <li>Virtual accounts for deposit collection — issue dedicated accounts per customer.</li>
          <li>Crypto on/off-ramps — accept stablecoins and settle to fiat.</li>
          <li>B2B invoice and vendor payments — automate cross-border vendor payments.</li>
        </ul>

        <p>
          Each use case includes a flow diagram, step-by-step integration guide, and links to the relevant API endpoints.
        </p>
      </div>
    </div>

    <div className="changelog-item">
      <div className="changelog-date">13/03/2026</div>

      <div className="changelog-card">
        <h3>Merchant Redirect URL for Collections</h3>

        <p>
          The{" "}
          <a href="/api-reference/collection/create">Initiate Collection</a>{" "}
          endpoint now accepts an optional <code>redirect\_url</code> parameter.
          After payment authorization (e.g. 3DS for card collections or open
          banking), the customer is automatically redirected to your specified
          URL with <code>transaction\_id</code> and <code>status</code> query
          parameters appended.
        </p>

        <ul>
          <li>
            Only HTTPS URLs are accepted (max 2048 characters).
          </li>

          <li>
            If no <code>redirect\_url</code> is provided, the existing default
            redirect behavior is used.
          </li>

          <li>
            Query parameters are appended with the correct separator whether
            your URL already contains a query string or not.
          </li>
        </ul>
      </div>
    </div>

    <div className="changelog-item">
      <div className="changelog-date">13/03/2026</div>

      <div className="changelog-card">
        <h3>Swap API Reference and Transaction Response Updates</h3>

        <p>
          We added documentation for the new{" "}
          <code>POST /api/external/swap</code> endpoint so businesses can swap
          funds between their own wallets.
        </p>

        <p>
          We also updated the transaction reference to document the latest
          response shape returned by the API.
        </p>

        <p>Other updates:</p>

        <ul>
          <li>
            Added the new <code>Swap</code> API reference section and navigation
            entry.
          </li>

          <li>
            Documented <code>type: SWAP</code> as a supported filter on the
            transaction list endpoint.
          </li>

          <li>
            Added <code>swap\_details</code> to both the list and show transaction
            response examples and schemas.
          </li>

          <li>
            Added swap-specific error examples, including validation and access
            restriction responses.
          </li>
        </ul>
      </div>
    </div>

    <div className="changelog-item">
      <div className="changelog-date">03/03/2026</div>

      <div className="changelog-card">
        <h3>Virtual Bank Accounts Guide & Payout Documentation Improvements</h3>

        <p>
          We added a new{" "}
          <a href="/guides/virtual-bank-accounts">Virtual Bank Accounts guide</a>{" "}
          that explains what Virtual Bank Accounts are, how to create them, and the
          prerequisites for each supported currency (NGN, GBP, EUR, USD).
        </p>

        <p>
          We also expanded the{" "}
          <a href="/guides/creating-first-payout">Creating your first payout</a>{" "}
          guide with currency-specific prerequisites and common error scenarios
          for NGN, GBP, USD, EUR, and CAD payouts.
        </p>

        <p>Other updates:</p>

        <ul>
          <li>
            Updated the Virtual Bank Account creation response message to reflect
            the new "initiated" status wording.
          </li>

          <li>
            Added new Virtual Bank Account validation error examples to the Payout
            API reference.
          </li>

          <li>
            Added request examples for every supported currency and payout method
            (NGN, GBP, USD ACH, USD Wire, EUR, CAD Interac, and Crypto) to the
            Payout API reference.
          </li>
        </ul>
      </div>
    </div>

    <div className="changelog-item">
      <div className="changelog-date">09/01/2026</div>

      <div className="changelog-card">
        <h3>Added Virtual Account Closure Endpoint</h3>

        <p>
          We added a new endpoint that allows you to close a virtual account.
          This could be useful for when a user no longer needs a virtual account
          or when a virtual account is no longer needed.
        </p>

        <p>
          Checkout the{" "}

          <a href="/api-reference/virtual-bank-accounts/close-a-virtual-bank-account">
            docs
          </a>

          {" "}

          for more information.
        </p>
      </div>
    </div>

    <div className="changelog-item">
      <div className="changelog-date">25/12/2025</div>

      <div className="changelog-card">
        <h3>New Blaaiz Platform API Documentation 🎉</h3>

        <p>
          Migrated to the new docs platform. It now features: a more intuitive
          navigation and a better search experience.
        </p>

        <ul>
          <li>A more intuitive navigation and a better search experience.</li>
          <li>An interactive playground for testing API endpoints.</li>
          <li>Refined API Reference layout and examples.</li>
        </ul>
      </div>
    </div>
  </div>
</div>