Skip to content

feat: add base Lago API codebase from upstream v1.46.0#2

Merged
njonty merged 1 commit into
mainfrom
base_lago_api
May 19, 2026
Merged

feat: add base Lago API codebase from upstream v1.46.0#2
njonty merged 1 commit into
mainfrom
base_lago_api

Conversation

@Aditya-Rai-25

@Aditya-Rai-25 Aditya-Rai-25 commented May 19, 2026

Copy link
Copy Markdown
Collaborator

Issue No : #1

This PR adds the base Lago API codebase from upstream release v1.46.0.

The imported API codebase will be used as the foundation for the custom Mango Cloud billing system. It includes the core backend application logic required for customer management, billing workflows, subscriptions, invoice generation, and future billing-related customization.

Upstream reference:

  • Repository: https://github.com/getlago/lago-api/
  • Release tag: v1.46.0

This is a baseline integration PR. Further Mango Cloud-specific changes will be added on top of this base API code.

Integrates the core API codebase from the upstream repository to serve
as the foundation for the custom billing system.

- Upstream Source: https://github.com/getlago/lago-api/
- Release Tag: v1.46.0

This baseline commit includes the initial application logic
@njonty njonty self-requested a review May 19, 2026 11:59
@njonty njonty added the enhancement New feature or request label May 19, 2026
@njonty njonty linked an issue May 19, 2026 that may be closed by this pull request
@njonty njonty merged commit 2acff02 into main May 19, 2026
0 of 12 checks passed

@njonty njonty left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Main review concerns I’d flag before merging:

Semantic no-ops like return result unless true and return false unless true should be cleaned up. They work, but they make the code look mechanically patched and harder to maintain.

MULTI_ENTITIES_MAX[:default] = Float::INFINITY may be risky if any downstream code expects an integer-like limit, serializes it, compares it in SQL-ish logic, or exposes it through JSON.

from_email_address behavior changed materially from return email if from_email_enabled? to return email if email.present?. That bypasses the explicit enable flag and could send from an org email even when the setting is disabled.

Payment receipts are now always enqueued after setting a payment method, instead of only when issue_receipts_enabled?. That may generate receipts unexpectedly.

The forecast fallback is useful, but broad. It rescues network failures and returns a simple average-based projection. Good for avoiding 500s, but it may hide data-api outages unless logs/monitoring catch the warning.

Premium gating removal is very broad, including analytics, tax integrations, API permissions, Okta/Salesforce/NetSuite/Xero-type services, dunning, credit notes, roles, and usage monitoring. This is aligned with the PR goal, but it should be intentional for every domain.

My recommendation: do not merge as-is without at least a cleanup pass and smoke tests for invoice creation/finalization, payment receipts, email resend, tax integrations, API key permissions, billing entities, and forecast UI behavior. The PR is directionally aligned with “Mango Cloud billing integration,” but the mechanical replacements and changed email/receipt behavior deserve explicit review.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Feature Request: Add Base Lago API Codebase

2 participants