Outbound Routes
Our outbound connection uses an outbound/forward proxy.
What does it allow you to do?
Like the inbound connection, the outbound/forward proxy allows you to rewrite requests and responses on the fly.
Lets you operate on data outside of the scope of your backend systems.
Set/Change/Strip Headers - perform any operation on the payload.
Modify the payload, even if it's not a strict redaction/replacement.
Perform Edge Computing, as needed for computing outside of the scope of your system (enterprise plans)
Adds an additional layer of security requiring proxy-authorization credentials and a root certificate to be set.
Is used to integrate into third party services and allows for configurations that are processor specific as mentioned in the integrations page.
Our outbound/forward proxy also allows for IP Anonymization as an additional upgrade.
How does it work?
The outbound/forward proxy directs traffic between your server (outbound) traffic, the VGS vault (where sensitive data is stored), and your third party integration
Example:
BEFORE: server.foo.com → api.worldpay.com
AFTER: server.foo.com →
<VAULT_ID>
.<ENVIRONMENT>
.verygoodproxy.com → api.worldpay.com
To achieve that you should set your server to send traffic through our outbound/forward proxy and create routes, filters and operations for your different API endpoints.
TLS Certificates
The outbound/forward proxy requires a TLS certificate. We have a different server certificate for each environment, SANDBOX and LIVE. You can find these certificates within the 'Code snippets' section of your dashboard.
Code Samples
Download and use appropriate TLS certificate for your vault environement to use in your application.
Run this sample code snippet in your terminal to see an example of data revealing.
curl https://echo.sandbox.verygoodvault.com/post --cacert path/to/sandbox.pem \
-x https://USiyQvWcT7wcpy8gvFb1GVmz:2b48a642-615a-4b3c-8db5-e02a88147174@tntsfeqzp4a.sandbox.verygoodproxy.com:8443 \
-H "Content-type: application/json" \
-d '{"account_number": "tok_sandbox_w8CBfH8vyYL2xWSmMWe3Ds"}'
For Spring-based Java applications, you can use our vgs-proxy-spring library.
Example Use Case: You need to send a customer’s Social Security number (SSN) to the Acme Background Check Service. You:
have previously collected the social security number
exchanged it for a VGS token to store in your database.
Now you should:
Create an outbound route in your VGS dashboard
Set Acme’s endpoint as the upstream host
Add a reveal filter in the request phase to replace the tokenized SSN with the real value
Add the route to your network as a forward proxy
The outbound/forward proxy directs traffic between your server (outbound), the VGS vault (where sensitive data is stored), and your third-party integrations, as illustrated by the image below.

Use this command for testing the setup to simulate your back end (using cURL)
`simulate-backend-integration`
How to implement?
We have several examples of API Call specific outbound implementations here.
`forward-implementation-example`
For many languages, setting the proxy as an environmental variable enables the outbound/forward proxy to be used at a framework or library level.
HTTP Basic Authentication
This enables a password of your VGS vault, so that only your application can reveal and access sensitive data. You must provide the username and password via the following URL format. https://<USERNAME>:<PASSWORD>@<VAULT_ID>.<ENVIRONMENT>.verygoodproxy.com:8443
Note: Some backend languages require you to access this url by passing auth in a different manner.
VGS outbound/forward proxy reveal operations require HTTP Basic Authentication using the username and password provided in the VGS dashboard.
It is up to you to protect these credentials; treat them like an API key. Please refer Basic Authentication for more information.
Tips on storing HTTP Basic Authentication Secrets Securely
Do not embed secrets directly in code.
Do not store secrets in files inside your application, including the application’s source tree.
If you do accidentally commit secrets to version control, revoke it immediately and generate a new one.
Ensure secrets do not appear in URLs or anywhere they can be captured in web server logs.
Review your code carefully and ensure it doesn’t contain secrets or any other private information before publicly releasing it.
Put the configuration file containing the secrets in the revision control ignore. This prevents committing them by mistake in the future.
Limit the usage of secrets
Restrict your secrets to be used by only the IP addresses, referrer URLs, and mobile apps that need them. Don't share your secrets with different applications. If more than one application uses the same API, register each application so you get a new set of secrets and update the secrets.
Delete unneeded secrets.
Update (Regenerate) your secrets periodically.
References:
Encrypted Communication
VGS supports encryption to protect communications between VGS and your web application. VGS supports the TLS cryptographic protocol. Support for anything less than TLS1.2 is officially deprecated.
For more information regarding TLS:
Upgrading your application
Alternative Using Reverse Proxy
If your server making outbound requests is already behind a proxy, it can be cumbersome to add a second, chained proxy. You can instead set up a VGS reverse proxy between your server and external services. This is simpler to implement, and suitable for testing, development, and building proof of concepts.
To implement, follow these steps:
If you already have an inbound route configured (which you likely do in order to securely collect PII), create a custom hostname for this route. For this example, suppose your custom hostname is backgroundcheck.yourcompany.com
Create an inbound route in your VGS dashboard
Set Acme’s endpoint as the upstream host
Set the route to allow requests to your custom hostname
Add a reveal filter in the request phase to replace the tokenized SSN with the real value
Modify your back end code to send the background check request to the custom hostname.
The data flow now looks like this.

To test the setup using cURL to simulate your back end, run this cURL command.
curl https://backgroundcheck.yourcompany.com/post -k \
-x https://tntsfeqzp4a.sandbox.verygoodproxy.com \
-X POST \
-H "Content-type: application/json" \
-d '{"ssn": "$VGS_TOKEN"}'
If you need any help setting up outbound connections, please contact us on site chat or at [email protected].
Last updated