Xendit Payment Integration Support

---

Status

Proposed

Context

Nango is an integration platform that lets applications connect to hundreds of third-party APIs through a unified, declarative configuration model. Third-party APIs are registered as providers in packages/providers/providers.yaml, where each entry defines the auth_mode, authorization/token URLs, proxy base_url, credential schema, and documentation links. Existing payment providers such as braintree and braintree-sandbox follow this pattern, using OAUTH2 auth and a categories: [payment] tag.

The supported auth_mode values are constrained by scripts/validation/providers/schema.json, which enumerates API_KEY, APP, APP_STORE, BASIC, NONE, OAUTH1, OAUTH2, OAUTH2_CC, CUSTOM, TBA, TABLEAU, JWT, BILL, TWO_STEP, SIGNATURE, MCP_OAUTH2, MCP_OAUTH2_GENERIC, INSTALL_PLUGIN, and AWS_SIGV4 . Every new provider must pass scripts/validation/providers/validate.ts, which enforces that a display_name, docs, provider SVG logo, and (for non-OAuth providers) a docs_connect page exist, and that credential fields required for the chosen auth_mode are declared.

Xendit is a Southeast Asian payment gateway (Indonesia/Philippines-focused) offering invoices, disbursements, payouts, virtual accounts, and e-wallet payment methods via a REST API secured with API key (Basic Auth-style secret key) authentication and HMAC-signed webhooks. There is currently no Xendit entry in providers.yaml, no corresponding SVG logo in packages/webapp/public/images/template-logos, and no documentation page under docs/integrations/all, meaning users cannot currently create Xendit connections in Nango.

Decision

Add Xendit as a first-class Nango provider by:

1. Registering a xendit entry in packages/providers/providers.yaml using auth_mode: BASIC (Xendit's secret API key is passed as the HTTP Basic username with an empty password, per Xendit's API convention), with proxy.base_url: https://api.xendit.co and categories: [payment].
2. Declaring the credentials schema (username/secret key) and a proxy.verification request (e.g., GET /balance) so Nango can validate credentials at connection time, consistent with validator requirements for BASIC auth providers.
3. Optionally supporting a xendit-webhook routing script if Nango needs to normalize/verify Xendit's x-callback-token webhook signature, following the pattern of webhook_routing_script used by other providers (e.g., hubspotWebhookRouting).
4. Adding the required assets: an SVG logo, a docs/integrations/all/xendit.mdx page, and (since BASIC is not in the OAuth exemption list) a docs/integrations/all/xendit/connect.mdx page describing how end users retrieve their API key from the Xendit dashboard.
5. Validating the new entry via npx tsx scripts/validation/providers/validate.ts and testing end-to-end locally through docker compose up and the local Nango UI, per the standard contribution workflow.

Consequences

Positive:

• Nango users can connect Xendit accounts and use the unified proxy/sync/action framework against Xendit's REST API without custom integration code.
• Follows established conventions, minimizing review overhead and maintenance burden.

Negative / Risks:

• BASIC auth mode in Nango is more loosely validated than OAUTH2 (only warnings are emitted if username/password credentials are missing), so extra care is needed in the connect documentation to ensure users configure credentials correctly.
• Webhook signature verification (x-callback-token) is Xendit-specific and not natively modeled by generic webhook_routing_script conventions used elsewhere; may require a dedicated verification script.
• No sandbox/live account separation is defined by default (unlike braintree vs braintree-sandbox); this decision should also address whether a separate xendit-sandbox provider entry is needed, mirroring the Braintree pattern.

Documentation API Reference

• https://docs.xendit.co/apidocs