API2PDF Infrastructure Fact Sheet

API2PDF Fact Sheet for Security, Infrastructure, and Sensitive Data

Background

  1. API2PDF is incorporated in Austin, Texas, United States and run by its two technical co-founders. There are no other staff.

  2. API2PDF is a remote company and has no dedicated office space.

  3. API2PDF was launched in 2018 and serves over 1400 active paying customers ranging from solo entrepreneurs to Fortune 500 companies.

  4. Our SaaS product has roughly 99.99% uptime historically, but we provide no official SLA and do not provide guarantees.

Infrastructure

  1. API2PDF is hosted on Google Cloud Run, which is a serverless, docker-based offering by Google Cloud with automatic scaling and security.

  2. The code is written in C# and compiled into a Docker Container.

  3. The service is running in Google’s us-central1 region. 

  4. Generated files are stored in a Google Cloud Bucket, also in the us-central1 region. The bucket has a policy attached which automatically self-deletes all files uploaded to the bucket after 24 hours. If you are processing sensitive data, see the section on Processing Sensitive Data down below.

  5. Request logs are stored in Microsoft Azure Table Storage.

  6. The portal, located at https://portal.api2pdf.com is hosted in Azure App Service on Microsoft Azure.

  7. API2PDF uses Stripe payment processor to maintain top-up on credit cards.

  8. The only individuals with access to the cloud environments are the two technical co-founders.

  9. API2PDF’s API layer interfaces with open source technologies such as PdfSharp, LibreOffice, Headless Chrome, and wkhtmltopdf. API2PDF is not responsible for the security of these underlying technologies, however, it does regularly deploy updated binaries when those technologies release updates.

API2PDF Security and Reliability

Platform dependencies:

  • Cloudflare (DNS management)

  • Google Cloud Run in us-central region (Compute)

  • Azure App Service us-east region (Portal for API key management and top up accounts)

  • Stripe Payments (automatic top up on accounts)

Your risks:

  • If there is any outage in the above dependencies, there may result in an impact to our uptime.

  • Service disruption could also happen from a malevolent or bad actor harming our service intentionally or accidentally.

  • We roll out an update to our platform that has a bug or error.

  • Your balance on your account runs out and your credit card on file fails to process and top up.

Risk mitigation:

  • To mitigate the last 3 items above, some customers with special requirements and enterprise needs are placed on a private cloud and no longer follow a "Pay As You Go" model, and go with a monthly fee. The API endpoint changes from v2.api2pdf.com, which is our SaaS line to something like yourname.api2pdf.com.

  • Other customers opt to purchase our docker containers and run our platform in their own hosting infrastructure so they have full control over the data and uptime. This is a one-time fee and you have the container in perpetuity.

Customer support:

  • System uptime is monitored 24/7 and receives highest priority if there is any service disruption of any kind.

  • General "how-to" questions and developer level support is provided via email with a typical response within 1-2 business days. These are "best effort" answers and we do not debug your code for you. Our support is scoped to ensure that the API provides the expected response based on the JSON payload posted, while acknowledging limitations outlined in our FAQ and of the underlying rendering engines (Chrome, Libreoffice, etc).

  • If your support needs exceed the above, a more advanced support subscription or consulting project can be discussed.

Processing Sensitive Data

We understand that there are many cases where you need to process sensitive data to generate PDF files. Financials, government documents, protected health information, and more. API2PDF offers 3 methods to mitigate risks associated with sensitive data.

  1. [DELETE ON COMMAND] By default, API2PDF self-deletes all files generated from our cloud storage buckets after 24 hours. This may be longer than you are comfortable with. If so, our API offers an HTTP DELETE request to our /file/{responseId} endpoint. By making a DELETE call to this endpoint with the responseId received from the original request to generate the document, you will delete the file from our bucket on command. See the utils section of our documentation: https://v2.api2pdf.com.
  2. [RETURN BINARY] By default, API2PDF stores the resulting file on our own cloud storage bucket and returns a URL to the generated file back to you. If you do not wish for the file to hit our bucket at all, you can specify a query parameter `outputBinary=true` in the HTTP Request. As a result, API2PDF will spit back out the binary of the PDF immediately instead of JSON. The headers of the response will include some meta data that would normally be a part of the JSON response.
  3. [STORE ON YOUR OWN CLOUD] Similar to #2, you can avoid hitting our buckets entirely but instead of receiving a binary back, API2PDF can PUT or POST directly to your own cloud storage. See our documentation for details, but in short, you can specify useCustomStorage: true, in your payload and then specify the storage options like so:

{

    "useCustomStorage": true,

    "storage": {

       "url": "https://some-presigned-url-api2pdf-should-PUT-request-to

    }

}

If none of the above approaches is sufficient for your needs, or if you require a HIPAA BAA (we do not sign BAAs), then contact us regarding hosting our Docker Container in your own cloud environment where you control the data from start to finish.