Skip to main content

Backend proxy

The standard Mambo integrations talk to the Mambo API directly: the JavaScript widgets call it from the browser, and the Node SDK calls it from your server. For most integrations that is exactly what you want.

Some organisations, however, need all Mambo traffic to pass through their own backend, with no Mambo API keys in any client code. The backend proxy is a small component you run on your own server that both the widgets and the Node SDK talk to. It holds the credentials, adds them to each request, and forwards it to Mambo.

What it does​

For every request from either client, the proxy:

  1. Keeps traffic on your own origin. Clients call your server, not Mambo, so there are no third-party calls from the browser and no cross-origin (CORS) requests.
  2. Keeps all keys server-side. The real keys live only in the proxy and are added to each request as it leaves your backend; nothing sensitive is ever exposed to a client.
  3. Scopes each request to the authenticated user. The proxy identifies the current user from your session and pins the request to that user, so a caller can only ever act as themselves.
Backend proxy request flowMambo widgetsNode SDKYour backend proxyholds the keyspins the userMambo APIsame origin · no keys in clientwith credentialsresponse

The two client paths​

A single proxy handles both kinds of client. You point each one at the proxy and configure it once:

  • Widget proxy — for the Mambo JavaScript widgets. You point the widgets' apiRoot at the proxy; it injects the JavaScript key.
  • Node SDK proxy — for the Node SDK. You point the SDK's base URL at the proxy; it adds the OAuth credentials.

The reference implementations show how to run a proxy that serves both paths.

What it does and does not solve​

  • It removes API keys from client code, and it stops the browser calling Mambo directly.
  • It does not, on its own, remove all external browser requests. The widget code, fonts, and images still load from Mambo's servers; achieving zero external requests also requires self-hosting the widget assets. See Widget proxy.
  • It does not replace your own authentication. The proxy trusts your backend to say who the user is, so you must authenticate the caller with your own session and derive the user identity server-side.
Note

With the proxy in place, Mambo trusts the proxy, and the proxy alone asserts who the end user is. The security of the whole integration rests on the "identify the current user" function you implement in the reference implementations.

Next steps​

  1. Widget proxy — point the widgets at the proxy.
  2. Node SDK proxy — point the Node SDK at the proxy.
  3. Reference implementations — run a proxy that serves both paths.