Database Delivery

• API - download a database whenever you choose, with an API key.
• Webhooks - a signed call to your endpoint each time a database you chose is updated.
• AWS S3 - each new build written to your Amazon S3 bucket, or to any S3-compatible storage.
• Google Cloud Storage - each new build written to your bucket by a service account you grant.
• Azure Blob Storage - each new build written to your container with a SAS token.
• SFTP - each new build uploaded to your server over SFTP, or FTPS.

Setting up a destination

Webhooks and storage are set up in the console, under Database, Delivery. Click Add destination, pick the kind, then fill in where it points and choose the databases it receives: any your organization holds a license for, each in the formats you want. Test connection checks the settings as saved, and Activate is open once a test has passed. Changing where a destination points sends it back for another test.

Setting up and changing delivery takes the Manage database delivery permission, which owners and admins have. Anyone in the organization can see where its databases go.

Each organization can have one destination of each kind. If you need more, tell us what for.

What a storage destination receives

The build that's current when you activate goes out first, then each new one. We compare checksums and send only the files that changed, so a database that wasn't rebuilt isn't sent again.

Latest only keeps one copy of each file under the folder you name, replaced by each build:

databases/vpn_ip_v1.mmdb
databases/vpn_ip_v1.mmdb.sha256
databases/manifest.json

Every build writes each one to a dated folder instead, laid out the way Athena, BigQuery and Spark read partitions. Set a number of days to keep and we delete the dated folders older than that:

databases/vpn_ip_v1/dt=2026-10-21/vpn_ip_v1.mmdb
databases/vpn_ip_v1/dt=2026-10-21/vpn_ip_v1.mmdb.sha256
databases/manifest.json

The .sha256 beside each file is in sha256sum format, so sha256sum -c vpn_ip_v1.mmdb.sha256 checks it. manifest.json is written last, once every file of a pass is in place, and lists each file with its checksum, size, build and when it was delivered. A job that watches for the manifest to change never reads a half-written set.

We only replace or delete what we wrote: the database files, their .sha256, the manifest and, for Every build, dated folders past their days. Deleting a destination leaves its files where they are.

When delivery fails

A failed delivery is tried again after 1 minute, 5 minutes, 30 minutes, 2 hours and 6 hours, then every 12 hours. After a day of failures we email the people who manage delivery in your organization, and after three days we pause the destination until someone resumes it. Each destination's History shows every file sent and every attempt that failed, with the reason.

Delivery of a database stops when your license for it ends, and its history says so. Every file we deliver is also in the Database page's Download history, named by its destination.